It seems like most languages are converging on a pretty standard feature set -- to the point where what "the" language is might not really matter because all its competitors will probably be roughly similar. I think we're at the point where almost every language will have:
- Lexical scope & closures
- Reflection
- Functions-as-objects
- The standard map/filter/reduce functions (sometimes under different guises and names)
- Immutability mostly by default, with the ability to override it
- Some hybrid of dynamic and static typing
The last one is probably a sticking point for a lot of people, but as far as I can tell it doesn't seem clear that either dynamic or static typing is obviously better in every context, and it seems like a lot of languages are recognizing that, either by introducing duck typing into a static context (IE, Go, or to an extent templates/generics), or introducing optional type constraints into dynamic languages via hints or asserts or just doing some JIT magic.
Anyway, I just see a lot of convergence. In 2000, different programming languages were really a lot different, in 2014... most of them have a pretty similar feature set.
They are all converging on these features because they have proven universally useful. But there is still a lot of work going on about other, new features. Some examples that interest me:
- effects and exceptions - should we use monads (Haskell), macros (Rust), handlers (Eff, algebraic effects), extensible rows (Koka)
- memory usage - how should we handle deallocation - using reference counting with infrequent GC (Python) or by being very careful (C++), using just GC and allocating freely (OCaml/Haskell, Java & Nim use "realtime" GC), using uniqueness semantics (Rust, ATS), using memory pools and great care (Objective C) - none of these approaches is perfect and optimal for all situations, and it's very frustrating that they don't really fit together
- safety and security - I'm really interested about provable programs, either dependent typing (Agda) or refined types (Liquid Haskell, ATS). Both require quite a bit of "static knowledge" - immutable data structures, or unique mutable data structures, and effect annotations for functions (plus, there are additional problems in lazy languages).
All of the above seem really hard to do using a dynamically typed language, but hopefully we can devise a way to have both a dynamic and a static provably efficient and secure code in the same program, same language, with clear split between the two.
Yesbut: these are features of the language(s) of the past, or at best the present.
I hadn't seen this c2 entry yet and was pleasantly surprised how many of those boxes my own Objective-Smalltalk[1] ticks:
- Borrows from Smalltalk but is not a direct descendant (LISP is also there, but less visibly)
- Dynamic typing as default with static typing as an addition (optional most of the time, not optional when interfacing with C). So far, there is only a rudimentary implementation, but more sophisticated static conversions are planned.
- Suitable for large and small applications. Yep, it does scripting and it does software architecture.
- Open Source. Well, yes.
- OO/Actors + FP. Currently, mostly OO. Higher Order Messaging gives a lot of the HOF/FP flavor, messages will be similar to generic functions (with a few crucial differences). Local vars will be immutable by default.
- Theorem Proving system. No, too big. But yes, you will be able to build one yourself and integrated it into the language as if it were built-in. A big part of making this possible are the flexible scheme handlers that support Polymorphic Identifiers[2], meaning you can define storage variables, while flexible messaging lets you implement sophisticated control structures.
- Scheme handlers + PIs also decouple storage definition from implementation, so you can have multiple implementations of the same schema. Automatic conversion is not built-in, but should be easy enough to build using the extensive meta-programming facilities.
- Simple syntax: yes, first thing I stole from Smalltalk, though it needs extending/adapting here and there to deal with the software architecture aspects.
- Easy to build DSLs. With Polymorphic Identifiers and flexible messaging, this is largely covered (also: the ability to define your own software-architectural connectors is largely isomorphic to being able to build your own language primitives).
- First class relations. Not full there yet, but first class references/variables + connectors means you have all the tools to build these.
- A later comment says 'I'm not sure the future of programming languages is even a "language." I imagine that we'll be connecting components on a bus architecture.'. Again, yes, ObjST's central theme is allowing language users to define architectural styles and then hook up the components.
- Graphical: once you have made your software architecture explicit using custom connectors and components, you will often be able to diagram substantial parts of applications.
The most interesting language design I have seen is Noether. It is a language built on multiple layers. Inner layers guarantee more invariants (say, immutability) but forbids constructs you may want to use. Outer layers are more expressive but guarantee less invariants. Importantly, inner layers are not different languages but sublanguages of outer layers, and inner layers keep guaranteeing invariants even when used in outer layers.
There is a language that fulfil all requirements. It borrows from Lisp, is neither C/C++, Java, nor any DotNet, supports dynamic typing with type inference, suitable for small and large applications, easy to do Meta programming, and write DSLs, is capable of both ahead-of-time compilation and interpretation; including the compilation of code at runtime, is Open source, is both OO and functional, supports Prolog, supports design by contract (by DSL extension), has several unit testing frameworks, supports relational DB features, and likely also the rest of the list.
Guess what that language is: It is called Lisp :-)
A classical version is SBCL. Modern versions are NewLisp, clojure and Shen (shenlanguage.org).
This just seems like a giant incoherent wish list with no central vision or any sense of the inevitable compromise required for any language of stature.
Your point makes all sense and I totally agree with it. And it made me remember an old joke about programming languages of the future, through a fictional book cover: [1]
I agree, it's basically saying that the programming language of the future should have all the good features of each language and none of the bad ones.
The future of programming should be one language for all layers of the stack, from the database to the model to the UI. I think that hints that it should be a form of declarative.
And if it's declarative, it should be focused on managing state.
And if it's a thin syntactical representation of its VM, instructions/code could be interpreted immediately at entry and be managed as state, so you wouldn't be working with a text file but querying the AST equivalent of what you wrote.
And if you do that, you can create the management tools and structures to truly understand and manage both data and code.
And if we do that, the future of programming would look less like today's mangle of a thousand wires to something more like sculpting and architecture.
> The future of programming should be one language for all layers of the stack,
Programmers will never agree on what this language should be.Ever.
Because different tasks require different features,a language that tries to have all these features will be regarded as a mess,and disliked because of it.
My person vision is lots of tiny languages that work together in such a way that you don't have to get out of their sweet spot. Of course, I'm not sure if its possible to do this nicely.
They are called Domain Specific Languages (DSLs). And it can be done reasonably well today.
Lisps are very good for producing DSLs; when you have macros you have very powerful control over the syntax and can therefore produce your own language within the language.
The Common Lisp LOOP macro is a great example of power of macros; though in that case it is debatable whether it was used for good or bad.
> My person vision is lots of tiny languages that work together
I personally can't work deeply in more than about 4 languages at once. This might be my memory, my experience level, or it could be a human limit, like the short-term memory 7±2 limit.
I think the "language of the future" will be the one that will allow people get results fast with little or no training. In other words, something that requires low skill. People hate learning and all they want is a magic button that just makes things happen (for the record, writing this doesn't make me happy at all).
Also, I predict something similar to the industrial revolution in software engineering, when high-skill difficult manual labor is replaced by factories operated by cheap low-skill workers.
I disagree with the idea that people hate learning. As a parent, it is quite clear that people love learning. They hate being reprimanded. Which is what a lot of people mistake for teaching.
This whole language of the future concept is just mistaken. The era of being able to choose a language, for most operations, is over. That's because the future will be (already somewhat is) the disappearance of PCs, the minimization of overt gadgets, and the rise of ubiquitous, invisible, small, smart, with no user serviceable parts. And in most cases with no option on programming languages. Embedded? You'll probably have a choice of C, C++ and maybe Rust. Android? Java. Apple? ObjC. You don't like the tools? Suck it up, there's too much momentum to re-invent the wheel even if you think square is a terrible shape. They already laid the roads in inverted catenaries.
This is nothing new. I learned more than 20 years ago that it is less pain to just use the languages that are part of the OS vendor SDK than spending development time writing yet another FFI wrapper.
This is how C got where it is now, as the language got adopted by OS vendors outside the UNIX world.
The language of the future is a language that allows the creation of DSLS per task. A DSL for compiler construction, model checking,driver construction,GUI programming. This language could compile to C or Assembly and be self-hosted.
I think whatever the language of the future will be, it's likely that we're going to have to give up editing a bunch of text files. Much of modern programming these days is really about workflow of large teams. It'd be nice to have richer editing areas that allow for things like embedded diagrams and videos as comments, annotations, hypertext links out to documentation and from documentation into code, review comments (similar to MS-Word), font size; colors; background colors etc. time-tracking for payroll, etc.
IDEs try to provide some of this layer on top of the piles of text files we use today, often supplemented with out-of-band config files and folder structure littering stuff all over the place. But there continues to be a proliferation of hacked on comment systems to handle things like method descriptions, code changes, reviews. People make changes in some code, then leave a comment in the code with the change they made, their name and email address so 2 years later somebody can try and track them down to remember the 2-line change they made 2 years prior. It's kind of absurd.
Imagine if I could just draw a box around a section of code, make the box dashed and fill the background with red and have a call-out annotation around it that says something like "highly performance sensitive, do not touch, see bane for problems" and "bane" was a link to my bug tracker page where you could immediately file an issue with that code?
And you knew the code had a problem because right above it, instead of some vague interpretive ASCII art describing the algorithm as a comment, there was a familiar vector graphic diagram and a set of equations all of us domain expert programmers know by heart. Only you noticed an error in the way I translated it from the textbook to code. You also tagged the couple lines I screwed up and wrote up a review comment in the sidebar (like in MS-Word) letting me know what you thought was wrong, that way when I go to my bug tracker, click the link that takes me directly to the code you wanted me to see, I see your review comment right next to the code in question, only it's not mixed up in the rest of the code comments explaining how the code works since it's semantically a separate thing.
I check out the problem and see that you're correct, I leave a response comment (which automatically notifies you via e-mail with a link to the bug tracker and to the code in question. When I go back out to the bug tracker the amount of time I was reviewing the issue is automatically logged, a diff is stored for review so everybody knows what I changed and the review comment and reply are automatically filled out in the tracker. My boss wants to check out the entire exchange, clicks my reply, is taken directly to the block of code in question and sees that I spent a reasonable amount of time doing the change (which he can see since the changes were tracked in the diff). I close the case and the review comments disappear from the code, leaving behind only good clean code and explanatory comments.
Now a year later, somebody turns on "see old bugs" and they see there was a problem there, the discussion, what the bug tracker #s were (with links they can follow), they can even play back time and see the 3 other edits that happened since then by simply moving a slider left to right.
Version control system commit comments are already very useful for many common development tasks, if done right (jira ticket number in each commit, commits divided properly, good commit messages with reasons for change). I wish there was more metadata there (like which tests failed during automatic build after each commit).
But I disagree using text as underlying data format is a problem. It's godsend. Text can be grepped, copy-pasted, diffed and versioned easily.
I cringe when I have to work with versioned word or excel documents. Working with versioned code is much easier.
you may think big red arrow would be nice to put in code, but how do I later search for all red arrows related to X, added by John between 3 and 4 months ago?
I have specification divided into 100s of versioned office documents. When I want to grep I have to know where to look (or zipgrep the underlying xml, which sometimes work sometimes doesn't).
If it was in a text format I could grep and see real differences, not edit history.
If it had embedded video I would need to watch the whole thing. And no - adding keywords isn't much help. I want to be able to search by content.
I don't think tools are the problem, but rather the process is.
I think it's a false idea the dev envinronment should cater to all stakeholders and parties of the process. Maintainting the theory of the system is one of the most important things but I'm really sceptical an IDE and a tool based process can do it for us.
Yes, there should be preferably only one place and way to do a particular thing but that does not mean they have to be all bound to the same tool.
I.e. the algorithm development you described in your example used completely unnecessary gaps in the communication. If the expert and you had reserved time with a whiteboard or a google hang out and ironed out the bugs right there without this nonsense going through the formal code review process it would have been much easier for all parties.
If your boss wants to participate in the process and does not trust you enough that so he needs to doublecheck on every trivial detail I would call that micromanagement. Or, he can join in the discussion when it is going on if he can have valid input into it. Otherwise he should trust you to do the right thing, and if he wants to check up on things the revision history in the spec document (or just v1 and v2 of the spec) should be sufficient combined with the code changes.
If the boss wants to doublecheck on everything or the process requires that all communication related to code changes (including that quick discussion you had with the chief architect at the urinals) is stored then the problem is in the process that is too heavy with non-value-adding baggage and no tool can fix it.
Storage of the spec should be formalized, code review should be formalized, but not all communications and work related to data that is input into these system should and can be formalized.
I think the idea that tools will fix the process is a faulty idea - the process needs constant vigilance from human participants and tools can only facilitate it. Expert work can be incredibly value adding but it needs to be first and foremost built on trust between individuals and clear ownership of responsibilities. Final products can and need to be bound to formal constraints - the process needs rigor on an individual level but not anal-retentive overseeing over every minutiae.
My main problem with this is the odd implication that text files are anything more than just a form of art. With rules. And, typically, well agreed meaning. You even refer to them as "interpretive ASCII art."
That is to say. Sure, I can not literally draw a box around some code. I can, however, put "boxes" around many parts of code. Be it by shuffling them away to another repository/file/namespace/whatever. Or simply appending "thinkThrice" to the function names.
More, it is easily argued that all art is "interpretive" at some level. The odd believe that a set of well agreed upon sets of interpretations (you know, the alphabet) are somehow less appropriate than mere free form lines on a wall is interesting.
I like this vision, but I just don't see it catching on. (Unless it has an obvious fallback to text). There are just so many tools that operate on text that you'd have to replace. I can't imagine people dropping, say, Git so that they can have videos as comments. At best you're probably dealing with some sort of markdown-esque meta-language that you embed in the comments.
The only significant language I can think of that shirked the code-as-files paradigm was smalltalk. Arguably that did not do the language a lot of favors, in that one of the main problems with smalltalk was that it always felt like a walled garden. It was definitely a very /nice/ garden, but interacting with the rest of the system was a very alien experience.
"Imagine if I could just draw a box around a section of code, make the box dashed and fill the background with red and have a call-out annotation around it that says something like "highly performance sensitive, do not touch, see bane for problems" and "bane" was a link to my bug tracker page where you could immediately file an issue with that code?"
PanuKalliokoski's short-term predictions were pretty prescient if they are more than a couple of years old. I wonder when he wrote them. Is there a way to view edit history on c2?
[+] [-] overgard|11 years ago|reply
- Lexical scope & closures
- Reflection
- Functions-as-objects
- The standard map/filter/reduce functions (sometimes under different guises and names)
- Immutability mostly by default, with the ability to override it
- Some hybrid of dynamic and static typing
The last one is probably a sticking point for a lot of people, but as far as I can tell it doesn't seem clear that either dynamic or static typing is obviously better in every context, and it seems like a lot of languages are recognizing that, either by introducing duck typing into a static context (IE, Go, or to an extent templates/generics), or introducing optional type constraints into dynamic languages via hints or asserts or just doing some JIT magic.
Anyway, I just see a lot of convergence. In 2000, different programming languages were really a lot different, in 2014... most of them have a pretty similar feature set.
[+] [-] tomp|11 years ago|reply
- effects and exceptions - should we use monads (Haskell), macros (Rust), handlers (Eff, algebraic effects), extensible rows (Koka)
- memory usage - how should we handle deallocation - using reference counting with infrequent GC (Python) or by being very careful (C++), using just GC and allocating freely (OCaml/Haskell, Java & Nim use "realtime" GC), using uniqueness semantics (Rust, ATS), using memory pools and great care (Objective C) - none of these approaches is perfect and optimal for all situations, and it's very frustrating that they don't really fit together
- safety and security - I'm really interested about provable programs, either dependent typing (Agda) or refined types (Liquid Haskell, ATS). Both require quite a bit of "static knowledge" - immutable data structures, or unique mutable data structures, and effect annotations for functions (plus, there are additional problems in lazy languages).
All of the above seem really hard to do using a dynamically typed language, but hopefully we can devise a way to have both a dynamic and a static provably efficient and secure code in the same program, same language, with clear split between the two.
[+] [-] mpweiher|11 years ago|reply
I hadn't seen this c2 entry yet and was pleasantly surprised how many of those boxes my own Objective-Smalltalk[1] ticks:
- Borrows from Smalltalk but is not a direct descendant (LISP is also there, but less visibly)
- Dynamic typing as default with static typing as an addition (optional most of the time, not optional when interfacing with C). So far, there is only a rudimentary implementation, but more sophisticated static conversions are planned.
- Suitable for large and small applications. Yep, it does scripting and it does software architecture.
- Open Source. Well, yes.
- OO/Actors + FP. Currently, mostly OO. Higher Order Messaging gives a lot of the HOF/FP flavor, messages will be similar to generic functions (with a few crucial differences). Local vars will be immutable by default.
- Theorem Proving system. No, too big. But yes, you will be able to build one yourself and integrated it into the language as if it were built-in. A big part of making this possible are the flexible scheme handlers that support Polymorphic Identifiers[2], meaning you can define storage variables, while flexible messaging lets you implement sophisticated control structures.
- Scheme handlers + PIs also decouple storage definition from implementation, so you can have multiple implementations of the same schema. Automatic conversion is not built-in, but should be easy enough to build using the extensive meta-programming facilities.
- Simple syntax: yes, first thing I stole from Smalltalk, though it needs extending/adapting here and there to deal with the software architecture aspects.
- Easy to build DSLs. With Polymorphic Identifiers and flexible messaging, this is largely covered (also: the ability to define your own software-architectural connectors is largely isomorphic to being able to build your own language primitives).
- First class relations. Not full there yet, but first class references/variables + connectors means you have all the tools to build these.
- A later comment says 'I'm not sure the future of programming languages is even a "language." I imagine that we'll be connecting components on a bus architecture.'. Again, yes, ObjST's central theme is allowing language users to define architectural styles and then hook up the components.
- Graphical: once you have made your software architecture explicit using custom connectors and components, you will often be able to diagram substantial parts of applications.
[1] http://objective.st/
[2] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media...
[+] [-] jamii|11 years ago|reply
[deleted]
[+] [-] al2o3cr|11 years ago|reply
In ten years, everyone will STILL know the language of 10 years in the future will be a Lisp. ;)
[+] [-] CmonDev|11 years ago|reply
[+] [-] sanxiyn|11 years ago|reply
http://www.infoq.com/presentations/noether
[+] [-] tel|11 years ago|reply
[+] [-] Dewie|11 years ago|reply
[+] [-] progman|11 years ago|reply
There is a language that fulfil all requirements. It borrows from Lisp, is neither C/C++, Java, nor any DotNet, supports dynamic typing with type inference, suitable for small and large applications, easy to do Meta programming, and write DSLs, is capable of both ahead-of-time compilation and interpretation; including the compilation of code at runtime, is Open source, is both OO and functional, supports Prolog, supports design by contract (by DSL extension), has several unit testing frameworks, supports relational DB features, and likely also the rest of the list.
Guess what that language is: It is called Lisp :-)
A classical version is SBCL. Modern versions are NewLisp, clojure and Shen (shenlanguage.org).
[+] [-] tomcam|11 years ago|reply
[+] [-] brudgers|11 years ago|reply
https://en.wikipedia.org/wiki/WikiWikiWeb
[+] [-] StephenFalken|11 years ago|reply
[1] https://i.imgur.com/dPjtGVj.jpg
[+] [-] Trufa|11 years ago|reply
[+] [-] david927|11 years ago|reply
And if it's declarative, it should be focused on managing state.
And if it's a thin syntactical representation of its VM, instructions/code could be interpreted immediately at entry and be managed as state, so you wouldn't be working with a text file but querying the AST equivalent of what you wrote.
And if you do that, you can create the management tools and structures to truly understand and manage both data and code.
And if we do that, the future of programming would look less like today's mangle of a thousand wires to something more like sculpting and architecture.
[+] [-] creadee|11 years ago|reply
http://www.red-lang.org/ (a Rebol-like language) promises to do that. And perhaps right down to the OS (if I've understood it correctly).
[+] [-] 14113|11 years ago|reply
https://en.wikipedia.org/wiki/Links_(programming_language)
http://groups.inf.ed.ac.uk/links/
[+] [-] aikah|11 years ago|reply
Programmers will never agree on what this language should be.Ever.
Because different tasks require different features,a language that tries to have all these features will be regarded as a mess,and disliked because of it.
[+] [-] sklogic|11 years ago|reply
[+] [-] david927|11 years ago|reply
[+] [-] ludamad|11 years ago|reply
[+] [-] Guthur|11 years ago|reply
Lisps are very good for producing DSLs; when you have macros you have very powerful control over the syntax and can therefore produce your own language within the language.
The Common Lisp LOOP macro is a great example of power of macros; though in that case it is debatable whether it was used for good or bad.
[+] [-] jared314|11 years ago|reply
I personally can't work deeply in more than about 4 languages at once. This might be my memory, my experience level, or it could be a human limit, like the short-term memory 7±2 limit.
[+] [-] 10098|11 years ago|reply
Also, I predict something similar to the industrial revolution in software engineering, when high-skill difficult manual labor is replaced by factories operated by cheap low-skill workers.
[+] [-] taeric|11 years ago|reply
[+] [-] JulianMorrison|11 years ago|reply
[+] [-] pjmlp|11 years ago|reply
This is how C got where it is now, as the language got adopted by OS vendors outside the UNIX world.
[+] [-] fithisux|11 years ago|reply
[+] [-] bane|11 years ago|reply
IDEs try to provide some of this layer on top of the piles of text files we use today, often supplemented with out-of-band config files and folder structure littering stuff all over the place. But there continues to be a proliferation of hacked on comment systems to handle things like method descriptions, code changes, reviews. People make changes in some code, then leave a comment in the code with the change they made, their name and email address so 2 years later somebody can try and track them down to remember the 2-line change they made 2 years prior. It's kind of absurd.
Imagine if I could just draw a box around a section of code, make the box dashed and fill the background with red and have a call-out annotation around it that says something like "highly performance sensitive, do not touch, see bane for problems" and "bane" was a link to my bug tracker page where you could immediately file an issue with that code?
And you knew the code had a problem because right above it, instead of some vague interpretive ASCII art describing the algorithm as a comment, there was a familiar vector graphic diagram and a set of equations all of us domain expert programmers know by heart. Only you noticed an error in the way I translated it from the textbook to code. You also tagged the couple lines I screwed up and wrote up a review comment in the sidebar (like in MS-Word) letting me know what you thought was wrong, that way when I go to my bug tracker, click the link that takes me directly to the code you wanted me to see, I see your review comment right next to the code in question, only it's not mixed up in the rest of the code comments explaining how the code works since it's semantically a separate thing.
I check out the problem and see that you're correct, I leave a response comment (which automatically notifies you via e-mail with a link to the bug tracker and to the code in question. When I go back out to the bug tracker the amount of time I was reviewing the issue is automatically logged, a diff is stored for review so everybody knows what I changed and the review comment and reply are automatically filled out in the tracker. My boss wants to check out the entire exchange, clicks my reply, is taken directly to the block of code in question and sees that I spent a reasonable amount of time doing the change (which he can see since the changes were tracked in the diff). I close the case and the review comments disappear from the code, leaving behind only good clean code and explanatory comments.
Now a year later, somebody turns on "see old bugs" and they see there was a problem there, the discussion, what the bug tracker #s were (with links they can follow), they can even play back time and see the 3 other edits that happened since then by simply moving a slider left to right.
[+] [-] ajuc|11 years ago|reply
But I disagree using text as underlying data format is a problem. It's godsend. Text can be grepped, copy-pasted, diffed and versioned easily.
I cringe when I have to work with versioned word or excel documents. Working with versioned code is much easier.
you may think big red arrow would be nice to put in code, but how do I later search for all red arrows related to X, added by John between 3 and 4 months ago?
I have specification divided into 100s of versioned office documents. When I want to grep I have to know where to look (or zipgrep the underlying xml, which sometimes work sometimes doesn't).
If it was in a text format I could grep and see real differences, not edit history.
If it had embedded video I would need to watch the whole thing. And no - adding keywords isn't much help. I want to be able to search by content.
[+] [-] fsloth|11 years ago|reply
I think it's a false idea the dev envinronment should cater to all stakeholders and parties of the process. Maintainting the theory of the system is one of the most important things but I'm really sceptical an IDE and a tool based process can do it for us.
Yes, there should be preferably only one place and way to do a particular thing but that does not mean they have to be all bound to the same tool.
I.e. the algorithm development you described in your example used completely unnecessary gaps in the communication. If the expert and you had reserved time with a whiteboard or a google hang out and ironed out the bugs right there without this nonsense going through the formal code review process it would have been much easier for all parties.
If your boss wants to participate in the process and does not trust you enough that so he needs to doublecheck on every trivial detail I would call that micromanagement. Or, he can join in the discussion when it is going on if he can have valid input into it. Otherwise he should trust you to do the right thing, and if he wants to check up on things the revision history in the spec document (or just v1 and v2 of the spec) should be sufficient combined with the code changes.
If the boss wants to doublecheck on everything or the process requires that all communication related to code changes (including that quick discussion you had with the chief architect at the urinals) is stored then the problem is in the process that is too heavy with non-value-adding baggage and no tool can fix it.
Storage of the spec should be formalized, code review should be formalized, but not all communications and work related to data that is input into these system should and can be formalized.
I think the idea that tools will fix the process is a faulty idea - the process needs constant vigilance from human participants and tools can only facilitate it. Expert work can be incredibly value adding but it needs to be first and foremost built on trust between individuals and clear ownership of responsibilities. Final products can and need to be bound to formal constraints - the process needs rigor on an individual level but not anal-retentive overseeing over every minutiae.
[+] [-] taeric|11 years ago|reply
That is to say. Sure, I can not literally draw a box around some code. I can, however, put "boxes" around many parts of code. Be it by shuffling them away to another repository/file/namespace/whatever. Or simply appending "thinkThrice" to the function names.
More, it is easily argued that all art is "interpretive" at some level. The odd believe that a set of well agreed upon sets of interpretations (you know, the alphabet) are somehow less appropriate than mere free form lines on a wall is interesting.
[+] [-] overgard|11 years ago|reply
The only significant language I can think of that shirked the code-as-files paradigm was smalltalk. Arguably that did not do the language a lot of favors, in that one of the main problems with smalltalk was that it always felt like a walled garden. It was definitely a very /nice/ garden, but interacting with the rest of the system was a very alien experience.
[+] [-] bblach|11 years ago|reply
I really like this imagination.
[+] [-] Marazan|11 years ago|reply
The issues is that now the code document is incredibly fragile. It can only be viewed, edited and manipulated with the one particular tool suite.
Raw text files suck but have amazing interoparability.
[+] [-] trias|11 years ago|reply
[+] [-] brudgers|11 years ago|reply
[+] [-] kristianp|11 years ago|reply
http://www.vpri.org/html/work/ifnct.htm http://lambda-the-ultimate.org/node/2483
[+] [-] mattxxx|11 years ago|reply
> Simple: The language of the future will have all the HolyWar features I like, and banish those that I don't. -- FillInTheBlankWeenie?
^ Only reasonable response. laugh.
There's questions all around about where domain-specific stuff is going. Regardless, I think there will be a lot more testing and program-proving.
[+] [-] jbzz|11 years ago|reply
[+] [-] blt|11 years ago|reply
[+] [-] Marazan|11 years ago|reply
[+] [-] sgt101|11 years ago|reply
Prepare for your mind to be blown.
[+] [-] cromwellian|11 years ago|reply
[+] [-] merdreubu|11 years ago|reply
[+] [-] CmonDev|11 years ago|reply
[+] [-] acd|11 years ago|reply
[+] [-] brvs|11 years ago|reply
[+] [-] sgt101|11 years ago|reply
[+] [-] rtpg|11 years ago|reply