I want a language that is designed alongside an editor/IDE. I want to stop putting comments in my code. I want it to be first-class for my code to be in the left pane and my comments to be in the right pane, always binded together with anchors but always separate so my comments don't have to adhere to the limitations of the code's text area.
And then I want to put rich things into my comments section like graphics and tables and such. And I don't want to have to write table-like Markdown or a shorthand that converts into graphics. I want all the WYSIWYG of Word or PowerPoint or Inkscape just right there feeling 100% natural and native.
Jupyter is pretty darn close to this. And I like it a lot. But I feel like I'm giving up a lot to make a notebook. I want this in a much more heavy lifting format.
WYSIWG is what you get, but not what you want. Anyone who has done serious work in Word, or some other WYSIWG editor has got to the point where the document becomes FUBAR, and you have to copy the plain text, and start again with a new document.
That is not acceptable for a programming environment. Copy an paste is the enemy of correctness.
No, you don't want this. Every new generation of new programmers since the 1960's talks about this, but nobody to date has actually written any useful program using pictures and prose.
Sorry. Code is code, that's what your job entails and you can't make programming into something it isn't.
In the 80s at FORTH, Inc. we had 'shadow blocks'. Forth code would go in one block and comments in the corresponding shadow block, and you'd flip back and forth with a keystroke. (We only had 80x25 text mode for coding, iirc. Your graphics would've been out of reach.)
I don't remember how or if people kept the shadow comments lined up with code (I was only there for one summer in high school), but you could extend the editor with ease, so...
This sounds like literate programming of some kind. A bit more advanced than Knuth's original WEB implementation, but certainly matching the idea that your code co-exists with discussion and diagram and so forth.
I used noweb at a previous employer, and it certainly was difficult to argue with the results; beautiful, readable documentation that existed as a first-class product, alongside the code it was describing. The quality of the software we generated was the highest I've ever seen in terms of things like deadlines and budgets and bugs and testing.
You could probably achieve this with an IDE that understands your rich text comments (maybe code them in JSON or base64 binary). To me it seems like a pure presentation problem.
Any language should be if not developed by the tool developer, at least developed with tooling in mind.
Compiliation for an editor (partial/incremental) is a very different beast from "normal" compilation, and any compiler that is first completed for regular compilation and then tries to address tooling as an afterthought, will ultimately never be useful in tools.
I realize writing a new compiler is hard enough in itself, but projects like the Roslyn poject shows it's at least feasible to make a compiler-as-a-service with both regular compilation and tooling in mind.
smalltalk, in particular pharo smalltalk, is doing exactly that. i don't think it supports including graphics in comments, but there is no reason that couldn't be changed.
to top it off, it had the potential for that already since its inception. so not exactly a new paradigm
> I want all the WYSIWYG of Word or PowerPoint or Inkscape just right there feeling 100% natural and native.
There's a thing for everyone, but that dystopian stuff you are describing here I cannot fathom even in my worst nightmares. The text file is a very powerful abstraction for programming and I hope it will never day.
It could take literate programming [1] to the next level. Existing tools like docco [2] can output beautiful documentation [3] with comments set alongside code. The language/editor described above would allow us to input code in the same side-by-side format.
Nice ideas but you might be better off with a folding editor or IDE where you can hide very long comment blocks.
If you haven’t tried a literate programming language, you might like it. You basically write a document with figures, etc. it is, with bits of executable code.
BTW, most of my coding in my last job was in Jupiter notebooks (to use Cloud GPU compute). Really not too bad for short ML scripts when you can still put slow changing library code you write in separate files. That said, not a great environment. I prefer configuring ITerm2 or xterm so I can get matplotlib plots to appear inline in SSH sessions.
PLT Racket lets you use images and other rich objects in their editor, and provides a framework for rich editors which that editor is written in. So there are pieces there.
Block oriented Forths used to use "shadow blocks" for documentation. You had a block that was code, and a fixed offset to a corresponding block that was documentation, with a keybinding to switch between them.
Various tidbits of this have been done in Smalltalk (of course).
But if you have already invested in a world of tool chains that assume ASCII or Unicode text streams as source code representation, then it's hard to get out of it.
You can do that for example with Haiku, so the comments would be saved as extra attribute. Sadly you would lost it if you move the sources to non-extra-attrib friendy FS.
On Haiku some editor already using this functionality to save the cursor position, window size and position, current selection, etc as attribute.
I've yet to see anybody that really bothers writing comments or documentation, and, more importantly, keeps it updated to match reality. This is only getting worse these days, where even major libraries and frameworks from Fortune 50 companies barely have autogen'd javadoc-style information available.
CNC programming with CAM software is very heavily visually oriented. I don't usually touch a single line of g-code other than to occasionally check certain things.
Your comment also reminded me of Godot's editor and gdscript. It's fairly domain specific(though the editor is actually a godot game). Everything's designed to work with gdscript. The language and the editor are designed to work seamlessly together in much the way you describe.
I don't think this is a good idea, and I don't think it will ever happen on a large scale, simply because programmers use different editors for valid reasons.
It's a dealbreaker if everybody working on the same project has to use the same editor.
Development practices that seem suboptimal for the individual are often optimal for teams. And teams develop all the major pieces of software we use.
I'm working on something similiar but way different. High-level REPL with a UI editor enabling you to rapidly develop over multiple levels of abstractions that end up doing token translations to existing or provided custom implementations. You'll basically define data, define flow and persepctives on data and that's it.
I think programming languages today focus too much on features and then they all look like another Algol variations with couple of features borrowed from elsewhere.
I don't think people these days try to understand what are the building blocks of languages and computation.
I'd wager the true next generation programming languages will be ultra minimalistic languages, retaining only the essentials while not losing on legibility.
Lisp for example is still not minimal as it has 'special forms', ie. hacks to make conditionals work. The unintiutive prefix notation also doesn't help.
Also not many languages allow people to explore true powers of deeper stack modifications by delimited continuations. Using them the users would be able to create their own looping and threading constructs as well as custom exceptions and iterator mechanisms and effect handlers.
It's important to realize that the economic incentives for truly innovative languages are bleak. The academia is stuck in incrementalism. Private sector wouldn't pay for it and the benefits would only be collected by cloud vendors, adding yet another trillions to their valuations.
* Moving towards representing code on disk as an abstract syntax tree, and anyone can edit with whatever syntax they prefer. Syntax becomes virtually irrelevant.
* The above point opens the possibility to represent code as visual graphs (even to code within virtual reality). Graphs and visual programming are useful, but to be able to toggle between textual and graph representation gives you the best of both worlds.
* Smarter compilers. For example: easy to use compile time constraints. Think about the ability to specifiy something like the minimum value an integer can be set to. This could allow the compiler to produce compile time errors for things like index out of bound errors, with zero runtime overhead. More complex constraints could be user defined. The mindset of programming could move to thinking about how you can do as much as possible at compile time.
* The ability to embed documentation alongside code. For most codebases the ability to understand the code is part of value of the code. Comments don't go far enough, particularly when working with visual concepts. Being able to embed readily accessible documention within the code could help dramatically.
> The dream of programming language design is to bring about orders-of-magnitude productivity improvements in software development tasks.
I can understand why there is such a focus on productivity, but I think it's awful for the industry when it's our number 1 priority. Productivity is meaningless if the thing that you are producing is of poor quality.
It's why we make web apps out of 500 npm dependencies when a native app would be faster and preferred by the user. It's why we use languages where we don't have to "fight against the type system" because we prefer writing code faster to writing correct code.
Again, I understand perfectly why this is the case. It just kinda makes me sad that we treat ourselves as garden hoses spewing out as much code as possible without as much thought into making a better product.
If I were to write an exploratory survey blog post of Next-Paradigm languages I would cover problems that are to be solved and ways to represent those problems.
That there are many alternative forms of computation, and that the inability to represent that form of computation in the host language leads to complexity and code bloat.
I've been trying to imagine what programming will look like in the far future, and I just can't believe that it will be fundamentally structured around typing English-like text into a text editor, with a smattering of tools to help manipulate the text and debug the resulting binary, like it is now. There has to be more that computers can do to augment our brains and help us become more efficient at writing code. Gary Bernhardt's "Whole New World" talk (https://www.destroyallsoftware.com/talks/a-whole-new-world) is a good start, but it could go so much further.
Unfortunately it seems like most working programmers are deeply suspicious of new paradigms for producing programs. Understandably so, since all the "visual programming" tools up until now have been either teaching toys or unusable disasters, but I think we're limiting ourselves tremendously.
But it may not be possible to arrive at my glorious imagined future incrementally. It may take some genius just sitting down and working on this for years and producing a completely finished system to convince people of its capability.
Sorry this is a bit lofty and light on specifics. It's more a feeling that I have that it would be ridiculous if programming in 2100 looked the same as it does now, and not something I've thought about deeply.
This is an discussion topic, and this text provides a viewpoint. However, from how I read it, the "current paradigm" is imperative languages like C/C++, and "next paradigm programming language" is Datalog (this word occurs 31 times on 9 pages of text).
What is missing are functional and descriptive languages.
No explicit loops? "heavily leverage parallelism, yet completely hide it"? lazy evaluation? This sound like functional languages.
"Example: An Interactive Graphical Application." describes HTML+CSS exactly.
I understand author really loves Datalog, but omission of other languages makes the message less effective.
The author is pushing a successor to Prolog. This is way outside the mainstream, but maybe it will work.
I suspect that future programming languages will either be garbage-collected or will have something like Rust's borrow checker. Nobody needs a new language with dangling pointers and buffer overflows. C++ is trying to retrofit ownership semantics, which is good, but has major backwards compatibility problems.
Indentation and code layout will be automatic. Either in the editor, or something like "go fmt". Nobody is going to put up with the indentation and the delimiters being out of sync.
Also, the ultra long lines of functional programming have to be laid out in some standard way to be readable.
Does each language really have to have its own build and packaging system?
For folks interested in future programming tools — be it languages, editors, IDEs, visual programming, new abstractions, what have you — I recommend looking at the https://futureofcoding.org community. The podcast has a number of great interviews with people exploring all corners of this problem space, and the Slack group is full of people actively working on these hypothetical-future tools and sharing their findings.
- Tiered abstraction levels. I want to write high-level functional code when I can, which expands to more complex code under the hood. When I want to I can instead manually expand the logic, perhaps the only time I need to code imperatively. Think a project today that has high level haskell or python code but implements bits in C where necessary. For the highest level bits, things like formal verification, safe concurrency, code contracts etc should be much simpler to use. For the low level bits, I'd just take responsibility for correctness (memory safety, formal correctness, concurrency) myself (like "unsafe" in Rust/C#). Perhaps the number of abstraction levels should be more than 2.
- Integration of tools: 1) Today a compiler, editor and VCS are 3 different tools, and their lowest common denominator today is text files. I'd like to see a system that version controls a syntax tree for a whole project, and allows semantic diffing. A build server could trivially do incremental builds, moving a symbol doesn't break history, reliably running only impacted tests for a 10h test suite is possible. This doesn't necessarily mean everything needs to be one big tool - but the lowest common denominator of tools could move from UTF-8 files to a binary representation of the whole syntax tree. Having a more complex binary representation would have drawbacks but also other benefits like trivial inclusion of a picture in a comment that can be previewed with a mouse hover in the editor, or displayed inline. 2) Better integration with documentation and issue tracking. Same as the AST representation: we need to be able to link documentation, pictures, links to issues etc from code in a way that doesn't rot if we change directory paths, issue trackers and so on. A broken link to a document in a comment should be a build error like any other error.
An overview of a problem that I run into is the need to pair some input, validate that input, query the system based on the input, expose the intermediate stages for inspection and modification by arbitrary consumers, conditionally modify the underlying system in some way, and provide well defined semantics around the outcome while handling failure recovery, distributing the processing into multiple, cancelable stages, and sharing the system context and other forms of memory with concurrent operations.
The right way to behave in each situation based off of the input, the state of the system, or failures encountered is determined by history and by many people.
A language that makes my job easier solves problems like:
1. Help me describe my system as straightforwardly as the above description
2. Prevent me from neglecting to handle failure and reduce the work to specify how to handle failure
3. Prevent me from introducing logic errors. e.g. concurrency without synchronization, or passing an int where a string is expected.
3a. Help me verify that my solution does what I expect.
4. Make it easy to accumulate data and pass information through various interfaces.
5. Make it easy to extend behavior without modifying existing code.
Given that we probably spend 95% of our time plumbing information, handling failure, and reducing logic errors, an order of magnitude of productivity increase is realistic. Choosing an algorithm or data structure is less than five percent of time allocated.
Rich Hickey and Clojure seems to focus on people like me. Rust seems to focus on another subset of the challenges I face. One of the useful ideas I've encountered is that coding is a specification design process rather than a manufacturing process. We start with an ambiguous description and specify behavior in increasing detail until a computer can work with it. The article suggests that we can subordinate some of this detail to the compiler. The details that it chooses to subordinate aren't the details that disrupt my productivity.
How about a gesture based programming language that translates to a visual one on screen? Is it so far fetched?
I've been typing programs for so many years I think we've gone as far as we could go with text, auto complete, live compilers, hot reload etc.
It wouldn't be that uncomfortable seeing a developer spends most of time reading / analysing and, god forbid, the open office would allow it (!@#$%^ noise): THINKING.
Here is a thought, want to make the future of programming languages? Remove distractions.
I've always felt that Ruby was the language that got closest to natural language or to natural pseudo-code while retaining conciseness and not getting overly verbose. I hope more new languages are heavily influenced by Ruby or go further towards being highly readable and concise.
Let's start with Fred Brooks: There aren't any new paradigms, techniques, or languages that (realistically) promise even a one-order-of-magnitude improvement in programmer productivity. (Paraphrased from "No Silver Bullet".)
That said, I think the biggest way a language can help is by having a great library. Code I don't have to write is a huge productivity boost. An outstanding example (for its day) was the Java library. It was like Barbie - it had everything. And it was organized (and documented) well enough that you could find what you needed pretty easily.
For the language itself, I don't have any great answers. But I observe that many of the comments here focus on syntax. Syntax matters, but don't forget that semantics matter also.
Every class / any construct gets a test stub. The compiler collects information during debugging on test data and how the elements of the applications are connected and expands tests based on this information.
I've often asked myself this question - are there any fundamental reasons why language needs to be the most expressive way to instruct computers? If not, what else?
.. and I've tried to resist answering it and letting the question ferment instead.
That article seems focused on languages aimed at the professional programmer.
I think the non-professional programmer is a bigger market. That is, the person who uses spreadsheets or writes some simple scripts.
Another issue is readability by non-professionals. Executives may not need to write business rules but they ought to be able to understand them enough to sign off on their correctness.
Most languages today come with a runtime. That makes it hard to interoperate with other languages/environments. To avoid this, a new programming language should either have no runtime (or a very minimal one), or be very explicit about which features it expects from its runtime and allow the runtime to be swapped out by something else (we might see something like that in the WASM sphere).
Furthermore, I believe we'll start seeing an increase in tooling around languages, and a focus on reducing iteration latency. Traditionally, REPLs/live editing have been mostly associated with higher level languages, but there's no reason that those things could not be applied to low level languages as well.
Finally, while I think that there will be always be room for both simpler and complex languages, the market for simple languages is somewhat underserved right now, so we'll start seeing more of those in the nearby future.
Disclosure: I'm the author of Muon, which is a new programming language that tries to embody these principles: https://github.com/nickmqb/muon
I'd love to see a modern successor to occam, or something similar that has first-class, painless multithreading.
It's strange to me that in this era of 32+ core machines, the language model is still single-threaded by default with (often significant) extra effort required to execute multiple bits of code simultaneously. Not to mention languages like python which restrict you to a single CPU core.
I hope the next languages will come from interactive theorem provers and program synthesis. I'd much rather work at the level of types, propositions, models, and proofs and solve the interesting problems. The rest is book keeping and often repeated over and over.
And I hope the interfaces for these languages won't require the use of a glowing screen and a sadistic keyboard. I'd rather like it for computers to disappear into the background. I'd like to reason about my programs in a physical space where I can freely walk around, write on a note pad, draw on a chalk board, converse, and re-arrange the room to my liking. I quite dislike how I've developed astigmatism, am at high risk for RSI, and probably other health ailments because we can't think of a computing environment better than what we have right now... just with more pixels, pop ups, nags, swishy animations, etc.
[+] [-] Waterluvian|7 years ago|reply
And then I want to put rich things into my comments section like graphics and tables and such. And I don't want to have to write table-like Markdown or a shorthand that converts into graphics. I want all the WYSIWYG of Word or PowerPoint or Inkscape just right there feeling 100% natural and native.
Jupyter is pretty darn close to this. And I like it a lot. But I feel like I'm giving up a lot to make a notebook. I want this in a much more heavy lifting format.
[+] [-] mr_toad|7 years ago|reply
WYSIWG is what you get, but not what you want. Anyone who has done serious work in Word, or some other WYSIWG editor has got to the point where the document becomes FUBAR, and you have to copy the plain text, and start again with a new document.
That is not acceptable for a programming environment. Copy an paste is the enemy of correctness.
[+] [-] otabdeveloper2|7 years ago|reply
Sorry. Code is code, that's what your job entails and you can't make programming into something it isn't.
[+] [-] abecedarius|7 years ago|reply
I don't remember how or if people kept the shadow comments lined up with code (I was only there for one summer in high school), but you could extend the editor with ease, so...
[+] [-] EliRivers|7 years ago|reply
I used noweb at a previous employer, and it certainly was difficult to argue with the results; beautiful, readable documentation that existed as a first-class product, alongside the code it was describing. The quality of the software we generated was the highest I've ever seen in terms of things like deadlines and budgets and bugs and testing.
[+] [-] maxxxxx|7 years ago|reply
[+] [-] solipsism|7 years ago|reply
Why would this require a new language? And why would it require a new editor?
For one thing, at a certain scale, code and documentation are examined in a browser more often than in an editor.
Your requirements seem too focused on insignificant details and not enough on the big picture.
[+] [-] zaarn|7 years ago|reply
[+] [-] alkonaut|7 years ago|reply
Compiliation for an editor (partial/incremental) is a very different beast from "normal" compilation, and any compiler that is first completed for regular compilation and then tries to address tooling as an afterthought, will ultimately never be useful in tools.
I realize writing a new compiler is hard enough in itself, but projects like the Roslyn poject shows it's at least feasible to make a compiler-as-a-service with both regular compilation and tooling in mind.
[+] [-] em-bee|7 years ago|reply
to top it off, it had the potential for that already since its inception. so not exactly a new paradigm
[+] [-] enriquto|7 years ago|reply
There's a thing for everyone, but that dystopian stuff you are describing here I cannot fathom even in my worst nightmares. The text file is a very powerful abstraction for programming and I hope it will never day.
[+] [-] divbzero|7 years ago|reply
It could take literate programming [1] to the next level. Existing tools like docco [2] can output beautiful documentation [3] with comments set alongside code. The language/editor described above would allow us to input code in the same side-by-side format.
[1]: https://en.m.wikipedia.org/wiki/Literate_programming
[2]: https://github.com/jashkenas/docco
[3]: https://underscorejs.org/docs/underscore.html
[+] [-] divbzero|7 years ago|reply
This specific bit reminds me of the elegant UX implemented in Typora. [1]
[1]: https://typora.io/
[+] [-] airstrike|7 years ago|reply
Check out Luna
https://www.luna-lang.org/
[+] [-] mark_l_watson|7 years ago|reply
If you haven’t tried a literate programming language, you might like it. You basically write a document with figures, etc. it is, with bits of executable code.
BTW, most of my coding in my last job was in Jupiter notebooks (to use Cloud GPU compute). Really not too bad for short ML scripts when you can still put slow changing library code you write in separate files. That said, not a great environment. I prefer configuring ITerm2 or xterm so I can get matplotlib plots to appear inline in SSH sessions.
[+] [-] madhadron|7 years ago|reply
Block oriented Forths used to use "shadow blocks" for documentation. You had a block that was code, and a fixed offset to a corresponding block that was documentation, with a keybinding to switch between them.
Various tidbits of this have been done in Smalltalk (of course).
But if you have already invested in a world of tool chains that assume ASCII or Unicode text streams as source code representation, then it's hard to get out of it.
[+] [-] santafe|7 years ago|reply
[+] [-] thrower123|7 years ago|reply
[+] [-] dTal|7 years ago|reply
[+] [-] grawprog|7 years ago|reply
Your comment also reminded me of Godot's editor and gdscript. It's fairly domain specific(though the editor is actually a godot game). Everything's designed to work with gdscript. The language and the editor are designed to work seamlessly together in much the way you describe.
[+] [-] AllegedAlec|7 years ago|reply
[+] [-] chubot|7 years ago|reply
It's a dealbreaker if everybody working on the same project has to use the same editor.
Development practices that seem suboptimal for the individual are often optimal for teams. And teams develop all the major pieces of software we use.
[+] [-] thecupisblue|7 years ago|reply
[+] [-] carry_bit|7 years ago|reply
[+] [-] profalseidol|7 years ago|reply
https://en.wikipedia.org/wiki/Structure_editor
I've seen that demo from JetBrains MPS, looks good. Hopefully it gets wide usage.
[+] [-] ccozan|7 years ago|reply
Then what you need is just a git blame(?) to visualize the current code section's comments.
Would this work?
[+] [-] danielovichdk|7 years ago|reply
I do believe a lot of code would benefit from better built-in documentation, which it essentially is.
I Will think about this some more
[+] [-] Razengan|7 years ago|reply
Swift Playgrounds has rich comments, but they are still inlined with code.
[+] [-] amrrs|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] judepereira|7 years ago|reply
[+] [-] snidane|7 years ago|reply
I don't think people these days try to understand what are the building blocks of languages and computation.
I'd wager the true next generation programming languages will be ultra minimalistic languages, retaining only the essentials while not losing on legibility.
Lisp for example is still not minimal as it has 'special forms', ie. hacks to make conditionals work. The unintiutive prefix notation also doesn't help.
Also not many languages allow people to explore true powers of deeper stack modifications by delimited continuations. Using them the users would be able to create their own looping and threading constructs as well as custom exceptions and iterator mechanisms and effect handlers.
It's important to realize that the economic incentives for truly innovative languages are bleak. The academia is stuck in incrementalism. Private sector wouldn't pay for it and the benefits would only be collected by cloud vendors, adding yet another trillions to their valuations.
Why bother.
[+] [-] kettlecorn|7 years ago|reply
* Moving towards representing code on disk as an abstract syntax tree, and anyone can edit with whatever syntax they prefer. Syntax becomes virtually irrelevant.
* The above point opens the possibility to represent code as visual graphs (even to code within virtual reality). Graphs and visual programming are useful, but to be able to toggle between textual and graph representation gives you the best of both worlds.
* Smarter compilers. For example: easy to use compile time constraints. Think about the ability to specifiy something like the minimum value an integer can be set to. This could allow the compiler to produce compile time errors for things like index out of bound errors, with zero runtime overhead. More complex constraints could be user defined. The mindset of programming could move to thinking about how you can do as much as possible at compile time.
* The ability to embed documentation alongside code. For most codebases the ability to understand the code is part of value of the code. Comments don't go far enough, particularly when working with visual concepts. Being able to embed readily accessible documention within the code could help dramatically.
[+] [-] dahfizz|7 years ago|reply
I can understand why there is such a focus on productivity, but I think it's awful for the industry when it's our number 1 priority. Productivity is meaningless if the thing that you are producing is of poor quality.
It's why we make web apps out of 500 npm dependencies when a native app would be faster and preferred by the user. It's why we use languages where we don't have to "fight against the type system" because we prefer writing code faster to writing correct code.
Again, I understand perfectly why this is the case. It just kinda makes me sad that we treat ourselves as garden hoses spewing out as much code as possible without as much thought into making a better product.
[+] [-] sitkack|7 years ago|reply
That there are many alternative forms of computation, and that the inability to represent that form of computation in the host language leads to complexity and code bloat.
Now how programs that embody those techniques are represented, I don't know what those languages are like, the semantics or the syntax.[+] [-] Analemma_|7 years ago|reply
Unfortunately it seems like most working programmers are deeply suspicious of new paradigms for producing programs. Understandably so, since all the "visual programming" tools up until now have been either teaching toys or unusable disasters, but I think we're limiting ourselves tremendously.
But it may not be possible to arrive at my glorious imagined future incrementally. It may take some genius just sitting down and working on this for years and producing a completely finished system to convince people of its capability.
Sorry this is a bit lofty and light on specifics. It's more a feeling that I have that it would be ridiculous if programming in 2100 looked the same as it does now, and not something I've thought about deeply.
[+] [-] theamk|7 years ago|reply
What is missing are functional and descriptive languages.
No explicit loops? "heavily leverage parallelism, yet completely hide it"? lazy evaluation? This sound like functional languages.
"Example: An Interactive Graphical Application." describes HTML+CSS exactly.
I understand author really loves Datalog, but omission of other languages makes the message less effective.
[+] [-] Animats|7 years ago|reply
I suspect that future programming languages will either be garbage-collected or will have something like Rust's borrow checker. Nobody needs a new language with dangling pointers and buffer overflows. C++ is trying to retrofit ownership semantics, which is good, but has major backwards compatibility problems.
Indentation and code layout will be automatic. Either in the editor, or something like "go fmt". Nobody is going to put up with the indentation and the delimiters being out of sync. Also, the ultra long lines of functional programming have to be laid out in some standard way to be readable.
Does each language really have to have its own build and packaging system?
[+] [-] spiralganglion|7 years ago|reply
[+] [-] alkonaut|7 years ago|reply
- Tiered abstraction levels. I want to write high-level functional code when I can, which expands to more complex code under the hood. When I want to I can instead manually expand the logic, perhaps the only time I need to code imperatively. Think a project today that has high level haskell or python code but implements bits in C where necessary. For the highest level bits, things like formal verification, safe concurrency, code contracts etc should be much simpler to use. For the low level bits, I'd just take responsibility for correctness (memory safety, formal correctness, concurrency) myself (like "unsafe" in Rust/C#). Perhaps the number of abstraction levels should be more than 2.
- Integration of tools: 1) Today a compiler, editor and VCS are 3 different tools, and their lowest common denominator today is text files. I'd like to see a system that version controls a syntax tree for a whole project, and allows semantic diffing. A build server could trivially do incremental builds, moving a symbol doesn't break history, reliably running only impacted tests for a 10h test suite is possible. This doesn't necessarily mean everything needs to be one big tool - but the lowest common denominator of tools could move from UTF-8 files to a binary representation of the whole syntax tree. Having a more complex binary representation would have drawbacks but also other benefits like trivial inclusion of a picture in a comment that can be previewed with a mouse hover in the editor, or displayed inline. 2) Better integration with documentation and issue tracking. Same as the AST representation: we need to be able to link documentation, pictures, links to issues etc from code in a way that doesn't rot if we change directory paths, issue trackers and so on. A broken link to a document in a comment should be a build error like any other error.
[+] [-] 6keZbCECT2uB|7 years ago|reply
The right way to behave in each situation based off of the input, the state of the system, or failures encountered is determined by history and by many people.
A language that makes my job easier solves problems like: 1. Help me describe my system as straightforwardly as the above description 2. Prevent me from neglecting to handle failure and reduce the work to specify how to handle failure 3. Prevent me from introducing logic errors. e.g. concurrency without synchronization, or passing an int where a string is expected. 3a. Help me verify that my solution does what I expect. 4. Make it easy to accumulate data and pass information through various interfaces. 5. Make it easy to extend behavior without modifying existing code.
Given that we probably spend 95% of our time plumbing information, handling failure, and reducing logic errors, an order of magnitude of productivity increase is realistic. Choosing an algorithm or data structure is less than five percent of time allocated.
Rich Hickey and Clojure seems to focus on people like me. Rust seems to focus on another subset of the challenges I face. One of the useful ideas I've encountered is that coding is a specification design process rather than a manufacturing process. We start with an ambiguous description and specify behavior in increasing detail until a computer can work with it. The article suggests that we can subordinate some of this detail to the compiler. The details that it chooses to subordinate aren't the details that disrupt my productivity.
[+] [-] keyle|7 years ago|reply
I've been typing programs for so many years I think we've gone as far as we could go with text, auto complete, live compilers, hot reload etc.
It wouldn't be that uncomfortable seeing a developer spends most of time reading / analysing and, god forbid, the open office would allow it (!@#$%^ noise): THINKING.
Here is a thought, want to make the future of programming languages? Remove distractions.
[+] [-] fouc|7 years ago|reply
[+] [-] AnimalMuppet|7 years ago|reply
That said, I think the biggest way a language can help is by having a great library. Code I don't have to write is a huge productivity boost. An outstanding example (for its day) was the Java library. It was like Barbie - it had everything. And it was organized (and documented) well enough that you could find what you needed pretty easily.
For the language itself, I don't have any great answers. But I observe that many of the comments here focus on syntax. Syntax matters, but don't forget that semantics matter also.
[+] [-] UweSchmidt|7 years ago|reply
Every class / any construct gets a test stub. The compiler collects information during debugging on test data and how the elements of the applications are connected and expands tests based on this information.
[+] [-] sriku|7 years ago|reply
.. and I've tried to resist answering it and letting the question ferment instead.
[+] [-] PaulHoule|7 years ago|reply
I think the non-professional programmer is a bigger market. That is, the person who uses spreadsheets or writes some simple scripts.
Another issue is readability by non-professionals. Executives may not need to write business rules but they ought to be able to understand them enough to sign off on their correctness.
[+] [-] nickmqb|7 years ago|reply
Furthermore, I believe we'll start seeing an increase in tooling around languages, and a focus on reducing iteration latency. Traditionally, REPLs/live editing have been mostly associated with higher level languages, but there's no reason that those things could not be applied to low level languages as well.
Finally, while I think that there will be always be room for both simpler and complex languages, the market for simple languages is somewhat underserved right now, so we'll start seeing more of those in the nearby future.
Disclosure: I'm the author of Muon, which is a new programming language that tries to embody these principles: https://github.com/nickmqb/muon
[+] [-] voldacar|7 years ago|reply
It's strange to me that in this era of 32+ core machines, the language model is still single-threaded by default with (often significant) extra effort required to execute multiple bits of code simultaneously. Not to mention languages like python which restrict you to a single CPU core.
[+] [-] agentultra|7 years ago|reply
And I hope the interfaces for these languages won't require the use of a glowing screen and a sadistic keyboard. I'd rather like it for computers to disappear into the background. I'd like to reason about my programs in a physical space where I can freely walk around, write on a note pad, draw on a chalk board, converse, and re-arrange the room to my liking. I quite dislike how I've developed astigmatism, am at high risk for RSI, and probably other health ailments because we can't think of a computing environment better than what we have right now... just with more pixels, pop ups, nags, swishy animations, etc.