Future of Programming Languages
c2.com
c2.com
- 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.
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.
[2] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media...
- 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.
There is also ML Kit's usage of regions - I guess this is roughly the same std::Arena library in Rust.
In ten years, everyone will STILL know the language of 10 years in the future will be a Lisp. ;)
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).
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.
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.
When we look at code as data, we can look at code in context.
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).
Red claims to be the world’s first full-stack language - http://www.red-lang.org/p/contributions.html
Anything that compiles to assembly is doomed to be a reheating of C leftovers.
Thats what Red/System is aiming at, ie. an alternative to C - http://static.red-lang.org/red-system-specs-light.html#secti...
PS. Hmmm... who/why downvoted my parent comment? The comment is factually correct, non-opinionated and with no added embellishments :(
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.
I'm curious what you mean by this. Is your definition of a DSL based on the language's syntax, or on the language's paradigm? Clojure's core.logic [1] provides logic programming, as apposed to functional programming, but maintains the syntax of a LISP.
(I work with embedded DSLs quite a lot, but in Scala, where infix and postfix operators are easy)
I'll have to try it out some day. Alas, one of too many that I have to try out some day.
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.
Edit: RE "Not same level as SQL", I meant in standardization. People can learn about SQL in isolation, too.
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.
This is how C got where it is now, as the language got adopted by OS vendors outside the UNIX world.
There are other compromises you make as a result, but that one feature is a huge win. (And yes, Objective-Smalltalk tries to extend that lesson of connectivity to other areas).
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.
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.
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.
I really like this imagination.
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 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.
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.
http://www.vpri.org/html/work/ifnct.htm http://lambda-the-ultimate.org/node/2483
> 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.
Prepare for your mind to be blown.