Live data from Hacker News

Future of Programming Languages

c2.com

21–30 of 73 posts

Re: Future of Programming Languages

#21
post #6
post #4

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.

I've just started looking at Rebol, and you may find it worth while -- it has a very interesting take on DSLs.

http://www.rebol.com/

Re: Future of Programming Languages

#22
post #20

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 comment…

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.

Re: Future of Programming Languages

#23
post #19

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-sk…

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.

Re: Future of Programming Languages

#24
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.

Re: Future of Programming Languages

#25
post #20

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 comment…

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.

Re: Future of Programming Languages

#26
post #7
post #4

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.

> 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.

Apparently the average is five chunks now

Re: Future of Programming Languages

#27
post #20

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 comment…

"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?"

I really like this imagination.

Re: Future of Programming Languages

#29

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 na…

We are working on a language that has no scoping, no data structures and no control flow (incidentalcomplexity.com). There is definitely still a ton of unexplored ground.

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

#30

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 na…

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.

[1] http://objective.st/

[2] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media...

Post reply on HN