I feel a little lost in this community. There are so many ways the “future of coding” will shape up. There is already many companies jumping in which have drastic different opinions on this future with different target users groups. Some are cloud backend focused, some are lambda languages, some are for gamers, some for data scientists, etc… I’m just curious where we can find “our people” and “our interests”. A gaming language is very different than a cloud-backend language, yet we seen to all jam ideas in a single thread.

I just posted a note elsewhere explaining why a single all-encompassing language, for all domains, is unlikely. The future is DSLs. So is the past, to be frank. Interoperability between DSLs is a fascinating topic.

Yeah, I certainly don't desire some totalizing worldview. I visualize the future of programming as the picture of the ant at the bottom of http://worrydream.com/#!/Links2013. The present of programming has the ants all living in the one/first branch they happened to climb up. The future requires backing up and exploring many other branches. Use the whole tree.

I’m glad you both agree. Perhaps my feeling/concerns are not well addressed in this threads origin. I’ll try to think of another way to present this idea.

We all have projects we like to talk about (mea culpa!) and so it's easy to fall into the trap of a one-track mind. But I don't mean to make it seem like my way is the One True Way or something like that. As someone posting more frequently than most I'll try to be more careful not to give that impression in future. And I could probably also be more quiet and give others space to talk 🙂 Everybody feel free to tell me to shut up anytime!

Thank you @Kartik Agaram. I agree too with what you said, especially in the engineering world: there is good reason to do thing many different ways. I’ll DM you to continue.

@Doug Moen

I just posted a note elsewhere explaining why a single all-encompassing language, for all domains, is unlikely. The future is DSLs. So is the past, to be frank. Interoperability between DSLs is a fascinating topic.

Can't find where you said that.. can you link to it?

Well, we are living in a present where one language+toolchain dominates in the web (the HTML/CSS/JS/framework), because the monopoly of browser manufacturers agreed among themselves to only allow this language. As Web Assembler creeps into the mix, this monopoly is going to end, hence the intense energy to prepare for that opening. In the back end of servers, it is save to say that PHP and Java have dominated the past, and those two are vulnerable. So there is an intense battle for the back end as well. And then there are specialty markets like ML, VR, 3D gaming, where intense battles rage. Of course no one single language will dominate all these areas, but in a given area, absolutely history shows that people coalesce to at least a 70% level around a language. It started with FORTRAN, then it was COBOL, and then Java (the COBOL of our time), then JS on the web, and in the future who knows. It certainly won't be Java or PHP on the backend, and it won't be JS in the web either. The existing tools are very costly, and with millions of new programmers coming into the field over the next 5 years per some estimates, the existing toolchains represent an arcane, ridiculously frustrating environment. The joke in the TV business was NTSC which is the US' analog tv standard meant never twice the same color, and i wish someone would come up with a cute name for CSS, which is one of the most frustrating languages ever devised. The tiniest error can cause your page to distort in a completely unpredictable manner, and people expect that to be the only way to go for the foreseeable future? Frustration = manhours wasted, and human costs have to be minimized, otherwise the industry will just outsource.

@Edward de Jong / Beads Project Your touch on some positions/observations that I absolutely agree with, which is why I believe (concerning the web backend languages only) instead of replacing PHP/Python/Ruby/Go/etc. we (and future programmers) need cloud glue-code to tie all these services together. FD this is what we are building at Storyscript. Regardless of Storyscript, I believe we need (a) less complexity, (b) more inclusive/diverse/flexible backends (c) better abstraction than k8s (d) tools that are more cohesive so the barrier to entry is less intense for our fellow new developers.

@Steve, I'm working on something where the language, editor, user interface, and everything about it, is 100% moldable by itself. I see the hard boundaries imposed by "language" or tools as something artificial that doesn't have to exist. Instead, the stuff things that fill these roles are just ordinary code (e.g. functions + data) that is not separate or special from the thing that is being built from it. Software is the most malleable (and self-malleable) material there is, so it's odd that this fact is not harnessed in the way that programming is done / software is created (e.g. with hard lines)

@Dan Cook would love to chat more! I’ll DM you 👍

Sturdy systems are built by changing as few layers at the same time as possible. If you start with a flexible runtime, language, editor, user interface, and apps, you will perhaps take on such a general problem that you won't be able to stabilize and thus finish anything. Part of the problem is that operating systems can even be unstable. Look at the chaos that Apple has created by intentionally breaking perfectly operating 32 bit programs in OSX, with the agenda to drive more software sales, but in the meantime wreaking havoc among the user base because they make it a single click to upgrade and it is irreversible. I don't think a small team has the time to build everything. Pharo has done it all themselves, and they have a fabulous IDE, probably the most sophisticated of all extant, but they spent so much time on itself they have almost no apps to show for it. Objective-C/Swift isn't perfect, but there are millions of apps running okay. One must balance productivity with theory.

Having the ability/freedom to easily change or control everything, is not the same thing as when and what you change, or how well organized /designed your software is (code, architecture, etc.). It's ironic that the most malleable and powerful building material in existence, is also so needlessly locked down in practice. Software libraries are a great example: Yes, it's insane to expect to invent everything from scratch every time. But the ability to be in compete control of those decisions, and roll your own when needed/best, is invaluable. Good software design demands both high expressibility, and the discipline / skills to express something coherent and sensible.

@Dan Cook Inspiring 👍 I think both you and @Edward de Jong / Beads Project are correct IMO it the approach that’s wrong. Here is my take on cloud development only. -- Replacing bottom-up (like Ballerina, Darklang, LunaCode, Bloomlang, and nearly thing else I’ve seen) has one fatal flaw: replacing and unlearning. I believe a long-term, top-down approach would solve both your arguments. I believe if we, the industry, builds products that don’s replace but abstract we can change the origin of development (which I believe is mostly middle stack today). Once you add a new top of the stack then the middle and bottom are easier to replace because you can do it with no one knowing.

That seems pretty totalizing, which is ironic given where this thread began 😛

@Kartik Agaram Should have made

cloud development only

more bold. The scope of my statement is specific to the cloud.

Even so, aren't you assuming a single product will take over the entire cloud development industry? Things don't ever seem that clean to me.

Not totally taken over, but Docker and Kubernetes have done quite well already.

Change, sure.

IMO we can’t replace the middle without moving to the top first.

I disagree, but that's mostly a subjective matter. I guess we'll see in 20 years which approach dominates, if indeed it's one of these. But it seems more objectively clear to me that you're only seeing a subset of the cloud development industry if you think Kubernetes is taking over. Any significant players who started out on other stacks will take years to migrate over, and by the time they do you'll have something else that seems like the 'top'. And then you'll have multiple tops as the industry fragments. In other words, it'll be like pretty much every segment of development in the last 30 years. If cloud development seems relatively homogeneous, it's just because it's only 5 years old. Give it time, it'll be the tower of Babel all over again.

True that 😉 RE

seeing a subset of the cloud development industry if you think Kubernetes is taking over.

my statement of Docker & K8S was simply an example of monumental change. By no means am I suggesting there is a one-size fits all product/solution of the cloud. I’m just saying there will be (and already are) abstractions that will change the landscape.

I think everyone has a valid view about problems with software, although our concerns and focus may be different. There is lot of noise and excitement in the industry and things that really are not making anything better -- or at least, if taken as a replacement or solution or cover-up of real problems, just adds more mess without fixing those problems. So for example, the debate between flexibile or concrete, functional or imperative, static or dynamic, ... It's not meaningful in the large! A wrench is not a good hammer! Screws are not "better" than nails! So Edward's response of X (as opposed to Y) being a mistake, is valid. And he's not mistaken that that's largely how the software works thinks. But ultimately the future is in finding the right synergy/applicability of both X and Y, for any X and Y. (C.A. demonstrates this well in Notes On The Synthesis Of Form)