Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 1 down vote favorite
2

Online (i cant remember where) i saw someone mention he wishes programming language has more built in features for tools like documentation and source control.

Now i dont understand what needs to be built in for source control since tools like git (sorry but i dont have much experience with others) has everything i need and is very easy to use.

Documentation i can understand, perhaps the ability to generate remote procedures calls from source to some kind of IDL would be cool. But really i dont understand what features a programming language can/should have that isnt tied with code generation and syntax (except the two i mention when it comes to libraries).

What ideas do you guys have? What is your wishlist?

share|improve this question
2  
"What is your wishlist?" Capital letters for proper nouns. It's spelled "I". – S.Lott Jan 12 '11 at 1:47
You may have read this amazon.com/Practical-API-Design-Confessions-Framework/dp/… or quotes related to it. – S.Lott Jan 12 '11 at 2:00
This is my favourite question lately :) +1 – acidzombie24 Jan 12 '11 at 5:22
@S.Lott: "I" is capitalised by typographical convention, not because it's a proper noun—it isn't one. And if the spelling and typography in a question bother you, you have the power to edit it. – Jon Purdy Mar 2 '11 at 21:11
1  
@S.Lott: If that were true, you wouldn't have known it was a personal pronoun. Then again, you didn't. ;) – Jon Purdy Mar 3 '11 at 0:27
show 4 more comments

5 Answers

up vote 10 down vote

Features like documentation or source control are not language constructs. I think people forget that things like the c++ STL, java API or javadoc are not actually part of the language itself. What people really want are more complete developmental frameworks.

share|improve this answer
I would upvote but what do you mean by more 'complete developmental frameworks'. Does that mean more libs or more syntax? – acidzombie24 Jan 12 '11 at 1:38
I loosely used the term developmental frameworks to describe mostly the widely available tools/libraries that support a given language such as the examples that I have given. .NET would probably be the biggest example of what I mean – Pemdas Jan 12 '11 at 1:54
I disagree. I think that at least documentation and maybe source control as well are very much language constructs. Having toyed around a bit with languages like Cobra, Ioke, Seph, REBOL, Emacs Lisp, Clojure and Python, which do have language-integrated documentation, the difference is like night and day and I despise RDoc, JavaDoc, ScalaDoc and all the rest. Being able to walk up to any running object in memory and asking it for its documentation is just friggin' awesome. – Jörg W Mittag Jan 16 '11 at 8:01
up vote 9 down vote

Things that every company does but does differently because it is not built-in to the language/librarty.

  • Standardized Logging
    • Sometimes you need customization but 80% of the time logging requirements are the same.
    • Yet every company has their own loggging framework.
    • So we can have standardized tools for reading and parsing log files.
    • So log file rotation and deletion are automated.
    • So log output is automatically generated.
  • Standardized Internationalization
    • You write the code with strings.
    • Compiler automatically spits out a resource file for the I18N team to customize
    • No other actions required by the dev team to use these resources.
  • Standardized versioning and automated checking of dynamic loaded objects.
    • I believe C# (or .Net framework) has this (could be wrong)
    • But other languages use conventions (like sticking version numbers in the file name).
  • Standardised cross platform language independant GUI infastructure
    • Thats a pipe dream.
    • but how many ways do we need to learn of putting a GUI together.
    • We should just be able to draw the GUI then wire the code into the generated infastructure.
  • Compiler detected parallelism.
    • Take threading out of the developers hands and put it into the compilers.
    • Parallel constructs built into the language rather than explicit threading.
share|improve this answer
1  
Most of that seems more "standard library" than "language" to me, but +1 for a good list. Especially the i18n string extraction thing. – Steve314 Jan 12 '11 at 2:01
Compiler detected parallelism...I have no idea how you could possible implement this. Threads are an operating system service not a language construct. How would the compiler know what code has higher priority. At best the compiler can detect instruction level parallelism, which it already does. – Pemdas Jan 12 '11 at 2:37
1  
About Internationalization, check out GNU gettext, which does what you want - except not being part of the compiler, but having a separate executable you can include in your build run. en.wikipedia.org/wiki/GNU_gettext – foo Jan 12 '11 at 2:57
1  
@Pemdas: Well I always quote Wiki as my authoritative source and limit my thinking to a decade old processor. For conventional languages this is probably true, that is why you need higher level language constructs that allow the parallelism to be expressed naturally. Current languages do not allow this and parallelism must be explicitly implement. Functional languages allow a more natural way to expresses parallelism but are hard to use (especially for business) so other paradigms that allow the ease of business expressive and natural parallelism exposure are required. Still a research topic. – Loki Astari Jan 12 '11 at 4:50
1  
@ Steve314, @foo: Yes I18N is covered by hundreds off tools. You just need to make sure you write the code in the correct way to make these tools work nicely. Its simple not hard its just time consuming and error prone. I just don't want to care about it. I want the language to do everything automatically. I should not have to take into consideration that the program will be run in Japan. I just want to write code. – Loki Astari Jan 12 '11 at 5:06
show 17 more comments
up vote 1 down vote

I would like the language to define a standard XML representation for an AST, and require that compilers can (optionally) generate it from source and compile from the XML. The representation should define UIDs for identifiers so that same-name-but-different-thing identifiers can be easily separated, among other relatively simple semantic stuff.

That way, you have an easy-to-work-with representation of the program, which can be used for a number of tools - the things I have in mind being unit testing (e.g. mocking by transforming the AST) and "context" input for domain-specific code-generating utilities, allowing checks relative to main-language code items that the DSL code references, and of course refactoring tools and other advanced IDE features - generating/modifying code based on the XML should be easier than working directly from source, especially if round-tripping information is embedded in the XML.

Even for relatively clean languages, parsing and semantic analysis is challenging, but for a working compiler that's obviously a solved problem. If compilers would generate a standard representation of source code for easy reading by tools, that existing solution gets more useful. Extra bonus - you know your tools are seeing the source the same way the compiler sees it, with no little parsing inconsistencies.

It could even be a step towards non-plaintext source code - if your IDE is primarily working from the XML to give a better representation of the source code that you're editing, perhaps there's little point in converting back the the original source, so that the XML effectively becomes the source. I'm not sure how good that idea is, but it would be fun finding out.

share|improve this answer
I agree with a standard representation. But I am not sure XML is going to be the best solution. Most IR are directed graphs (If they were trees then XML would be OK). Or at least textual versions of directed graphs. – Loki Astari Jan 12 '11 at 18:07
@Martin York: What does 'IR' stand for? Do you think JSON is a good representation? – acidzombie24 Jan 12 '11 at 23:10
@acidzombie24: IR => Intermediate representation. Compiler read source convert it into IR optimize the IR then generate assembly from the IR (obviously oversimplified example). – Loki Astari Jan 13 '11 at 7:29
@Martin - XML can hold a digraph. For example, a single parent can have a "nodes" element and an "edges" element, each containing a collection for fairly simple records. It's not a particularly human readable representation but that's usually true of XML anyway. And you could very easily write a tool that could dump out a graphviz dot file for a particular digraph. – Steve314 Jan 15 '11 at 1:33
@Martin - I should have said before - although the XML would be a representation that is intermediate between source and compilation (ignoring the XML-rather-than-data-structure metarepresentation) it wouldn't be what is normally called an intermediate representation. An IR is normally "virtual machine code", and a "virtual machine assembler" representation works for that, but is little use for what I had in mind. The XML would be more a representation of the AST (Abstract Syntax Tree), which is basically what the parser spits out, with only minimal attention to semantic issues. – Steve314 Jan 16 '11 at 18:34
up vote 0 down vote

There is nothing like that on my wishlist.

Logging, Threading, GUI interfacing and about anything else that takes place at runtime belongs into a library. I wish some of the good existing solutions for these topics were official, generally accepted (and implemented!) standards, but it's OK the way it is.

Version control does not belong into language, and never should - like editing, it is strictly outside the language. You don't use the source to check it in itself, don't you. You use an IDE or something - and that's where these features belong. Bug tracking, versioning, collaboration, all these are activities and therefore belong into the tools used in working on the source.

Documentation is part of that, too, but needs a bit of linking with the source. Oxygene and JavaDoc aren't exactly bad ideas IMHO, but I would much prefer an accepted standard for liniking from source with a single (G)UUID to the documentation which is placed in a separate file - would be the cleanest way. Comments are to comment the source, not really suitable for extensive documentation.

About internationalization, that is also a non-issue. Outside of testing, you shouldn't put any text into your source that is intended for the user to read. It's separate resources, and there are well established tools for handling them as well. And if you are lazy and still need internationalization, there is the gettext family of tools.

Strings are supposed to be Unicode or UTF-8 anyways, IMHO. This should be the default, and can be set as such in many environments.

Most things are there already, really. You just need to know about them and use them.

Languages should be concise and tight, in my opinion. Few keywords, powerful syntax. Everything else belongs outside, into libraries and tools.

And if there is/were a good set of free and open standard libraries, I would be pleased.

share|improve this answer
Would any of the downvoters care to leave a comment as to why? – foo Jan 12 '11 at 23:06
I didnt DV but i removed my UV so it may look like a DV. I decided i agreed with your GUID comment and Languages should be concise and tight but felt that quote was actually saying dont add in extra stuff. I think MORE things should be in a language so i left it as +0 – acidzombie24 Jan 13 '11 at 7:25
Thank you for explaining your removed UV. I'm indeed saying don't add to the language, add to the standard libs (as, for example, Java and Python try to do). So your interpretation (and hence edit) is correct. – foo Jan 13 '11 at 23:20
up vote 0 down vote

Most of the times a programming language <important>syntax</important> is not much related to features for tools like documentation and source control. Specially, because there are several tools, and each tool works different.

Special comments or directives like "///", are better, because can be handled and extended for each particular tool.

I worked with several PHP projects, once, I had source code that use a special "/** ... */" comment for one tool that generates documentation, and another project with "/// ..." for another tool. And both where the same programming language.

And the funny thing, is that, I wanted to make my own document generator, with it's specific comment syntax, for the same programming language...

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.