half of the people in this group, when they think of "future of coding", imagine more convenient, more grpahically interactive IDE environments, where you use drag and drop mechanisms, and extrapolate from autocompletion to not just a word but a phrase. Others imagine more robust languages which free the programmer from the drudgery of debugging, which some estimate takes 85% of all programming time. A lot of people over-estimate the time it takes to enter the code, and under estimate the time it takes to get it working perfectly. I would be very interested in the group members divulging what percentage they estimate of the total time making a program to be debugging.
3 years ago
I can't say that writing and debugging are distinct for me, but the part that is more debuggish feels like it's 95% at least. Of course, writing is fun in a way that debugging almost always is not and time flies.
3 years ago
RE: https://futureofcoding.slack.com/archives/C5T9GPWFL/p1545813427072200?thread_ts=1545720056.038800&cid=C5T9GPWFL(Warning: Contrarian Take, Coming In Hot!)And yet, in so many other fields, the moment of creation is far removed from the moment of reaction, and it's fine. When I paint a painting, I'm not going to get feedback from my audience (or any buyers) until after the painting is done. Some painters might benefit from getting that feedback throughout the creative process. Most (myself included) would surely find it stifling.Point: It is at least conceivable that there are benefits to the lack of immediate feedback when programming. It'd be interesting to try to spitball what those benefits might be. It requires a broader sense of "feedback" than just "does it compile and what does it do when run?", which is of course a broader sense than the one @shalabh intended, but worth considering because we're all here exploring that broader space.
actually Mr. Reese has an excellent point. If Tolstoy wrote War & Peace a sentence at a time, and had a group of editors watching over his shoulder as he wrote longhand onto paper this very complex novel, would it have helped or hindered? i think most of us can imagine it would have prevented the creation of the work. If people want to have any fluidity in their creative process having interruptions that distract you from the larger goal is indeed counter-productive. When you want to check a section, you might indicate such, It is an interesting contest, to see if the graphical input of programs can beat the textual in flexibility and speed at the same time. Clearly that is the goal of many of the people on this board. I am of the opinion that we must improve the underlying language first before attempting a graphical input assist, because the current languages have deep intrinsic flaws that prevent robust programs, and hinder interchangeable parts. If we create a graphical programming system, let's say something like Luna is trying to do, how do you copy/paste code unless you have an underlying textual form. So whatever graphical assist one invents, it must produce a textual form in order to be printed, and sections adapted. If you pin a programming language to a single IDE and editor you doom that language, because no IDE lasts nearly as long as a language does. A language has a grammar, a set of abstractions, and a runtime to support its execution on the operating system of the time. An IDE is a much more complex thing, that usually depends deeply on the graphical primitives of an OS.
Slightly different take on the previous thread: Fortnite itself actually is the future of programming! (Well, sorta.)Shared-virtual-world games like Fortnite (and Minecraft before it) are successful primarily due to their status as digital social environments. In fact, these sorts of games are increasingly taking over the role of “third places”, or semi-public community hangout spaces (https://medium.com/s/greatescape/fortnite-is-so-much-more-than-a-game-3ca829f389f4).One of the big problems with these new digital third places is that they’re not open to improvement or modification by the people who spend their time there. The rules of Fortnite, and the map you play on, are determined by some distant corporation; even if everyone in a given player community would favor a certain adjustment to the rules, there’s no way for that community to implement their desired change short of petitioning the developers to implement it globally. Making digital third places approachably programmable from within would change this dynamic, while simultaneously giving a whole bunch of people both a motive and a means to learn to program.We can look to MUDs as a key source of inspiration here. MUDs embody a tradition of allowing players to shape their shared digital world – including, in some cases, by scripting dynamic behaviors for NPCs and objects. Getting approachable scripting tools embedded in a widely used modern digital social environment would be a major coup in terms of giving users back some control over the digital spaces they inhabit.Situating a “future of programming” vision in this context also suggests a particular focus on building tools that enable communities of novice user-programmers to collaborate, self-govern, and learn together. Empowering individual users to shape the environment is necessary but not sufficient; the real leverage will come from empowering small communities of people with varying levels of skill and interest.You can maybe think of the end goal here as something like a community code-garden, where most users know just enough about how to program the environment that they can chip in to help improve it in small ways here and there. Meanwhile, a few informally designated “local experts” will sometimes step up to take the lead on larger-scale changes or improvements.I keep meaning to write about this at greater length, but here’s a related Twitter thread I wrote when some of this stuff first clicked for me: https://twitter.com/maxkreminski/status/1030838313429528576
Hi all - I hope you have had a relaxing holiday season. I'm posting to remind everyone of the upcoming Salon des Refusés 2019 Call for Papers which you can read at https://www.shift-society.org/salon/call-for-papers/ . This is a pretty new venue for paradigm-busting new approaches to programming - check out some of the interesting contributions we've received in our first two years. There are lots of folk here who have posted thought-provoking and counterfactual views on how we need to reframe the task of programming so I feel sure we could get many great contributions and start some great conversations. In general we would be far more interested in some unpolished, rough work that is much more challenging to the status quo than some more well-worked out and mature work that is less disruptive - save that for other venues. A word to the wise - although the official deadline is next week a rumour on the grapevine suggests that this will end up being extended a couple of weeks : P - so don't shy away because you think there's too little time to get your ideas down. Looking forward to hearing what you are thinking about!
I wanted to share a great talk about teaching computational thinking by Brown Univ. professor Shriram Krishnamurthi.
Also excited to see @Max Kreminski here. Your post on problem-solution ordering (https://mkremins.github.io/blog/doors-headaches-intellectual-need/) has strongly influenced how I think about learning and teaching programming. In this talk Prof. Krishnamurthi adds an insight about inductive learning where you go from concrete instances to a generalized understanding (problem-solution ordering) - it is difficult to transfer a concept thus learned to other instances of the same underlying problem. So while inductive learning is essential to understand a problem in the first place, students also need to examine the problem purely in abstract so that they are able to transfer it to any other instance.