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.
Future of Programming Languages
21–30 of 73 posts
Re: Future of Programming Languages
#22I 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 comment…
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.
Re: Future of Programming Languages
#23I 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-sk…
Re: Future of Programming Languages
#24- 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.
Re: Future of Programming Languages
#25I 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 comment…
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.
Re: Future of Programming Languages
#26My 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.
> 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.
Re: Future of Programming Languages
#27I 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 comment…
I really like this imagination.
Re: Future of Programming Languages
#28Re: Future of Programming Languages
#29It 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 na…
The last few decades of PLT research feel like a huge depth-first search. Our notions of what programming is settled down in the 80s and haven't changed too much since. I suspect that PLT could do with a little more explore and a little less exploit.
Re: Future of Programming Languages
#30It 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 na…
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...