On the positive side, things that were cutting-edge hard problems in the 80s are now homework assignments or fun side projects. For instance, write a ray tracer, a spreadsheet, Tetris, or an interactive GUI.

On the negative side, there seems to be a huge amount of stagnation in programming languages and environments. People are still typing the same Unix commands into 25x80 terminal windows. People are still using vi to edit programs as sequential lines of text in files using languages from the 80s (C++) or 90s (Java). If you look at programming the Eniac with patch cords, we're obviously a huge leap beyond that. But if you look at programming in Fortran, what we do now isn't much more advanced. You'd think that given the insane increases in hardware performance from Moore's law, that programming should be a lot more advanced.

Thinking of Paul Graham's essay "What you can't say", if someone came from the future I expect they would find our current programming practices ridiculous. That essay focuses on things people don't say because of conformity and moral forces. But I think just as big an issue is things people don't say because they literally can't say them - the vocabulary and ideas don't exist. That's my problem - I can see something is very wrong with programming, but I don't know how to explain it.

People still typing the same Unix commands into terminals do it because it's still the most efficient way to accomplish those things. Maybe it's always going to be the optimal solution for some tasks.

Just because an idea is old, doesn't mean it's bad or wrong.

    (doseq [x (range|cursor|)]
      )

Text also doesn't provide you with stable IDs. If I previously had function "foo" in a file and now that's gone, but there's a function "bar" in the same place with roughly the same code, does that mean it was renamed? Or did foo get deleted and we need to surface that anything using foo is an error? How would you know? The only thing you have to go on is position and position can change for all sorts of other reasons. I ran into this problem with trying to do functions in single editors: when the file can change in any way, reconciling that file with your previous view of the world is tremendously difficult.

I'd be happy to share these techniques sometime.

[1] http://catenary.wordpress.com/2011/04/19/naurs-programming-a...

* making your lexer incremental first, memoize tokens between edits so you have something to attach trees to that will still be there after the next edit!

* Match braces (or determine indented blocks) separately before you even bother parsing. This makes incremental parsing more robust, and it is really easy to do without parsing information (unless your language overloads brace lexemes, like Java generics do! Scala didn't have this problem however). Also, autocomplete braces even if your users really hate that, because otherwise you won't have anything nice to reason about 99% of the time (indented languages are really better here for obvious reasons). Tell them to just use emacs if they don't like it.

* The last thing to do is just memoize parse trees (by attaching them to your memoized tokens) and then replay parsing on trees whenever their parses could have changed. So if their is an edit, invalidate the inner most tree, or multiple trees if the edit occurs at a boundary. If a child tree parse changes, invalidate its parents. Log your symbol table additions so you can undo them when they are no longer done on a parse (or the parse tree is deleted); trace your symbol table references if the symbol binding for the name being looked up changes, and don't worry about type checking in a separate pass, because you can just replay the parse multiple times if necessary.

The last point is quite fascinating and something I'm working on right now to turn into a more general programming paradigm. Check out:

http://research.microsoft.com/apps/pubs/default.aspx?id=2112...

So here we are in 2014, with all that nice GUI live development environments (Interlisp, Smalltalk, Mesa/Cedar) lost to people that prefer a UNIX System V clone.

Likewise, Smalltalk and Mesa were both hugely influential in everything from C, C++, Java and beyond.

Given that, it seems more likely that graphical development hasn't taken off because it isn't good enough yet. All developers have prejudices, but they typically have to yield to superior methodologies.

Quoting Alan Kay

<quote> Now, the abortion that happened after PARC was the misunderstanding of the user interface that we did for children, which was the overlapping window interface which we made as naive as absolutely we possibly could to the point of not having any workflow ideas in it, and that was taken over uncritically out into the outside world. </quote>

> Given that, it seems more likely that graphical development hasn't taken off because it isn't good enough yet. All developers have prejudices, but they typically have to yield to superior methodologies.

The only existing mainstream environment that can replicate some of the live coding experience of the said systems is Mathematica.

That is why for old guys like myself it is so interesting to see all the live coding discussions that happen on HN, from people that never used those systems or at least saw them being used.

And then tiling window managers were invented, and users rejoiced.

He also goes on to praise NLS, which failed precisely because of its steep learning curve and unsuitability for large swaths of the personal computing market.

Incidentally, that's why a GUI with overlapping windows succeeded : because it was familiar, intuitive and simple.

IMO, it's rather telling that none of the major DE's or WM's involve automatic tiling. This, despite the fact that there are a myriad of solutions available [1]. It's not about "better" or "worse", but suitability for a given market.

[1] If anyone's interested, I highly recommend i3. As powerful as xmonad with a fraction of the configuration hassle.

[X] I don't presume to know -- it's just the first system I came into contact with which has this concept.

[1] http://ipython.org/

(edit: apparently there's some magic markup I don't yet understand.)

It was already present on the Xerox PARC systems.

You can see a little bit of it here about Symbiotics, http://www.loper-os.org/?p=932 at minute at minute 30.

Or here for Smalltalk-80, https://www.youtube.com/watch?v=JLPiMl8XUKU

I had all this stuff in the first chapter(the history) of my HCI-course at University. So, luckily, the younger programmers learn about stuff that already has been there, back in the days.

But I was baffled by what bad stuff must have happened to the world, that we ended up where we are now and not where we should have been.

The UNIX shell is quite primitive by comparison.

"The UNIX shell is quite primitive by comparison."

I don't believe that's still the case (and hasn't been for some while). If you believe it is, rather than just making assertions please explain what you think is missing from bash in screen in urxvt.

- bash is not a REPL with support for live coding.

- as consequence of the last point, bash cannot provide graphical output and respective manipulation of system data structures

Writing data to /proc to alter the OS behavior, is pretty basic compared with changing OS behaviour with a "doit" message on a expression block.

EDIT: For better understanding, imagine using something like Mathematica as an OS shell.

"bash is just one of many possibilities, so bash != UNIX shell. It is not available by default in all UNIX systems"

Bash is one example of a modern UNIX shell. It is not the only example - there are some that are more advanced in some ways, and some that are less advanced in some ways. I wasn't saying "BASH IS ALL UNIX", I was picking a specific setup as a point of comparison.

"bash is not a REPL with support for live coding."

What are attributes of a REPL which you see bash as lacking? Clearly, it Reads, Evaluates, and Prints. If you just object to the particular language, fine, there are certainly things to object to there - though I think it's pretty great as UI. It's certainly atrocious when you try building anything large out of it.

"as consequence of the last point, bash cannot provide graphical output and respective manipulation of system data structures"

That's mostly false, which you touch on immediately following.

'Writing data to /proc to alter the OS behavior, is pretty basic'

It can get arbitrarily sophisticated, but...

'compared with changing OS behaviour with a "doit" message on a expression block.'

I don't know what this means, please elaborate.

"For better understanding, imagine using something like Mathematica as an OS shell."

There's too many things that can mean for it to aid my understanding much. Do you mostly refer to the ability to embed graphics in the interactive session while retaining a scrolling log? or are there other relevant attributes I'm not following?

All those demos you see from Bret Victor are based on the experience to do live coding originally developed in these environments.

The operating system and applications are blended.

UNIX shell is based on the principle you write little programs in whatever language you feel like and you just have pipes, command line arguments and exit codes as communication mechanisms.

In Xerox PARC environments, you have a REPL experience where you can make use of any function or object in the whole OS and applications. You can change them dynamically (Interlisp, Smalltalk) or via module reload (Mesa).

Since the language of the REPL is the one of the system, you can do tasks, like select something with the mouse and then apply a REPL script to the currently selected graphical objects.

Just a few dummy examples, do a map over all selected windows to change their size for automatic tiling.

Or go over the paragraphs on the text editor and right align them.

The shell blends application macros, operating system scripts and live coding all in the same way.

For graphical editing in the shell you can pretty print data structures so that when you type a variable that represents a graphical structure, it gets drawn graphically in the command line.

You get to change running applications state from the shell, without requiring some kind of network protocol or shared memory API that they need to implement. Any public function or object can be directly accessed and manipulated.

Think of the whole experience as something like DrRacket or Mathematica being the complete OS.

That said, little of this is really dependent on another model. It seems your complaints boil down to 1) applications may do a poor job defining interfaces (which is either also true in the PARC setup, or they ignore the need to define interfaces in which case things are unlikely to be stable), 2) everything is too stringly typed (which I mostly agree with, though there are advantages to it), and 3) these (plus cultural attitudes) lead to insufficient/inappropriate infrastructure (which I also agree with - "the application" is typically harmful in the UNIX model).

Having said that, there doesn't seem a theoretical difference in capabilities except for the choice of a more sophisticated terminal (which is something I'd like fixed on modern systems).

As an amusing aside, "Just a few dummy examples, do a map over all selected windows to change their size for automatic tiling." I did literally this just the other day with bash + ratpoison.

[1] http://www.evanmiller.org/dont-kill-math.html

This seems like an almost willful misunderstanding of what programming is. The power of programs does NOT come from their syntactic structure. The power of programs comes from the non-linearity of programming language semantics -- I can trivially write a program that (theoretically) calculates a number too large to represent in the number of atoms in the universe.

The command line amplifies (non-linearly) what you can conventionally do with simple UIs. As a trivial example:

    $ mkdir -p src/{main,test}/{scala,java,resources}
    $ touch src/{main,test}/{scala,java,resources}/.keep

Pictographs work for the illiterate, but that doesn't make them the most efficient interchange mechanism.

While I enjoy the shallow dig, I think this is a pretty great metaphor generally, in a deep (and less condescending) way.

If you drop me in France, and I don't speak French, I'll probably do a lot of communication with pointing and grunting, and I'll probably be able to accomplish simple tasks (particularly with an ideographic picture book on hand). Expressing more complicated things that way is pretty intractable, however. Learning to speak French is the solution, but it's a lot of work.

Moreover, there are certainly contexts where pointing makes more sense ("I'll take that one, that one, and that one" versus trying to pick out differentiating features or count).

Well, I for one am typing the same Unix commands and some new Unix commands into 58x170 terminal windows (on my laptop - bigger at work), and at work my builds run in 10s of seconds if I run tests. In many ways a much better experience, and one that it's easier to build still more great stuff into/atop without breaking the basic model.

Well yes, there are always people who stick to the older methods, or sometimes the situation calls for programming through a terminal window, but there have been big advancements since those methods, like the great environment of Visual Studio and such. Why do you say programming has gone nowhere because there are people who don't use the newer advancements?

Speaking for myself, its because Visual Studio and its ilk don't feel like advancements. They feel like bandaids. They do their damnedest to reduce the pain of programming by automatically producing boilerplate, auto completing words, providing documentation, and providing dozens of ways to jump around text files.

Personally, I don't feel that the bandaid does enough to justify using it (granted, my main language doesn't work well with Visual Studio, so there's that too).

The main source of the pain is, to me, is that we're still working strictly with textual representations of non-textual concepts and logic, no matter how those concepts might better be rendered. We're still writing `if` and `while` and `for` and `int` and `char` while discussing pointers and garbage collection and optimizing heap allocation... Instead of solving the problem, we're stuck down describing actions and formulas to the machinery. No IDE does anything to actually address that problem.

Sorry, rant, but this problem certainly resonates with me.

I can't see any issue with representing logic abstractly with symbols. It's the same for calculus. Of course the ideas we're representing aren't actually the things we use to represent them, the same as written communication.

Non-textual programming has been explored to some degree, such as Scratch, but it's not seen as much of a useful thing.

>Instead of solving the problem, we're stuck down describing actions and formulas to the machinery. No IDE does anything to actually address that problem.

Describing actions and formulas to a machine in order to make it do something useful is pretty much the definition of programming. IDEs make it a more convenient process.

Unless you want to directly transplant the ideas out of your neural paths into the computer, maybe some AI computer in the future based on a human brain, this is how it's going to be.

That's the problem: text isn't abstract enough. So we put some of the text into little blobs that have names (other methods), and use those names instead, and we call that "abstraction," but black-box abstraction doesn't help us see. The symbols in calculus, by contrast, are symbols that help you see. The OA is calling for abstractions over operating a computer that help us see.

Written language is wonderful in many respects, and I sometimes thing people discount these things out of familiarity. Keyboards too- you can do things very quickly and very precisely with keyboards. Those things matter for your sense of productivity and satisfaction.

People still do that?

We still use 'if' and 'then', but higher level languages like Ruby and Python have eliminated pointers and their ilk from day-to-day discussion, relegating heap allocation discussion to the halls of specialized conferences, while many programmers go about their day-to-day activities skipping over the pain of garbage collection.

They may not win language shootout speed tests, but they remove a lot of programmer pain and help with how long it takes to write code.

Somebody has to design and engineer the hardware and every level of abstraction between that hardware and whatever abstraction layer the "average" developer uses.

For languages specifically such as Java, which have very verbose syntax, and huge amounts of boilerplate for large projects, then sure, an IDE is an improvement.

But even IDEs, really, haven't much changed. And the fact that we even still can have the discussion, sort of proves that it's not that much of an improvement.

The core of his argument was the sequential text in 20+ year-old languages.

A radical change would be similar to how 3d materials & render chains have improved in the last 20 years. From editing Renderman text files, to the nodes system: https://www.google.co.uk/search?q=blender+render+nodes That's a radical shift.

There's a lot more to an IDE than code generation and autocomplete (even if those are very useful and save me a ton of time). Finding all references to a variable or function (simple text searching does not do this nearly as well - the IDE actually analyzes the language and knows what points to what). Immediately letting you know if the syntax is wrong. Very visual and intuitive debugging (it goes to the line # and lets you hover over a variable to see its contents). Jumping to a variable's definition.

There have been experiments with non-textual programming, such as Scratch, but it hasn't really proven to be very useful. If there's going to be some radical shift, it might come from AI and brain scanners maybe?

http://www.codeproject.com/Articles/13127/Create-a-Debugger-...

http://visualstudiogallery.msdn.microsoft.com/eedc48e7-5169-...

(but of course one has to think outside of the "evil MS" box)

Yes, IDEs help a lot with some of those tasks. But we're really still improving programming in a very evolutionary way - which isn't bad. For sure c# is more powerful and interesting than 1990 era c++. But ultimately, it's not that different, really.

To me, that's the interesting thing about lightroom, and all that stuff. We're able to explore some of the concepts of programming from the old smalltalk systems in a modern way. And maybe, we'll find ways of programming which do actually look different from the old ways. Maybe not.

Visualising functions as things which we can glue together, transform, pass data through, etc. I'm very interested to see where it all goes.

not today, but in 5, 10, 20 years from now.

Recent experiences have shown me that flowchart systems are really really specialized tools that require a lot of training to be able to use with a modicum of success.

There are very few problem domains where I believe they provide a more accessible and expressive solution than plaintext.

Anyone who thinks it hasn't improved should take a look at the description of the program used as an example in David Parnas's classic 1972 paper 'On the Criteria to be Used in Decomposing Systems into Modules' ( https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/crit... )

It's a KWIC (keyword in context) program and he says a competent programmer should be able to code it in a week. These days it's about 5-10 minutes in Ruby or Perl.

Think about boiling water. You boil it till 100 Celsius scale. You keep heating it, but it won't attain more temperature, without turning it into steam. Now think about it, we do not need steam but we need liquid water for survival.

I'm using 120x40, thank you very much

There is always a need for two types of languages, higher level domain languages and general purpose languages. Building general purpose languages is a process of trying to build abstractions that always have a well-defined translation into something the machine understands. It's all about the cold hard facts of logic, hardware and constraints. Domain languages on the other hand do exactly what he describes, "a way of encoding thought such that the computer can help us", such as Excel or Matlab, etc. If you're free from the constraint of having to compile arbitrary programs to physical machines and can instead focus on translating a small set of programs to an abstract machine then the way you approach the language design is entirely different and the problems you encounter are much different and often more shallow.

What I strongly disagree with is claiming that the complexities that plague general purpose languages are somehow mitigated by building more domain specific languages. Let's not forget that "programming" runs the whole gamut from embedded systems programming in assembly all the way to very high level theorem proving in Coq and understanding anything about the nature of that entire spectrum is difficult indeed.

I never suggested otherwise, just that when you're in a domain you should be in that domain. That solution requires something more general purpose to glue domains together, which is the crux of the problem. What does such a language look like? How do you ensure you don't lose all the good properties you gain from the domain specific languages/editors when passing between them?

I think you present a false dichotomy though. General purpose languages are just as much about encoding a process. The distinction between compiling to the machine vs some abstract machine also isn't really relevant: this is about semantics, not implementation. And if you let implementation dictate the semantics you won't get very far from where we are now.

> What I strongly disagree with is claiming that the complexities that plague general purpose languages are somehow mitigated by building more domain specific languages.

I never said that :) I said that programming would be greatly improved by being observable, direct, and incidentally simple. And again those have nothing to do with what "level" you're programming at, they're just principles to apply. I do think there is a general solution that can encompass most of the levels (though I'm not interested in trying to do that any time soon), but there is a common case here and it certainly isn't high level theorem proving or embedded systems. It's stupidly simple automation tasks, or forms over data apps, or business workflows. The world works on poorly written excel spreadsheets and balls of Java mud. You don't have to fix everything to make a huge impact and the things we learn in doing so can help us push everything else forward too.

That's a very interesting (and I'm betting hard to solve) problem! However, it's very hard for me to see how Aurora would help with that. From the demo, it looks like yet another visual programming system; such systems don't seem particularly interoperable.

We ended up abandoning that path for now as there are some aspects of functional programming that prove pretty hard to teach people about and seem largely incidental.

The pervasive use of ordering in functional programming inhibits composition. (Even in lazy languages the order of function application is important). Compare to eg Glitch or Bloom where different pieces of functionality can be combined without regard for order of execution/application. This better enables the ideals that BOT was reaching for - programming via composition of behaviour. In a BOT plugin you can not only add behaviour but remove/override other behaviours which turns out to be very valuable for flexible modification of Light Table.

A more concrete problem is displaying and explaining nested scope, closures and shadowing. As a programmer I have internalised those ideas to the point that they seem obvious and natural but when we showed our prototypes to people it was an endless source of confusion.

Functional programming is certainly a good model for expressing computation but for a glue language the hard problems are coordination and state management. We're now leaning more towards the ideals in functional-relational programming where reactivity, coordination and state management are handled by a data-centric glue language while computation is handed off to some other partner language.

That's what really killed it for me and also one of the things that I found pretty surprising. Tracking references is apparently way harder than I realized. And while I thought we could come up with a decent way to do it, it really did just confuse people. I tried a bunch of different strategies, from names, to boxes that follow you around, to dataflow graphs. None of them seemed to be good enough.

But as to graphs vs trees I don't think it is so clear-cut. Good arguments on both sides of that issue.

True, but one of the problems which Bret Victor and Chris Granger set out to solve with LightTable (and is mentioned here in §"Programming is Unobservable" and §"Programming is Indirect") is that the tooling for using current programming languages hasn't meaningfully changed since the 70s or 80s.

I agree that generalising over all programming languages is near-impossible, but even the most 'bare-metal' languages only manipulate models of the computer hardware.

I have a ServiceControllerServiceProvider which disagrees.

If you are using card[0][12] to refer to Card::AceSpades, well, time to learn enums or named constants. If, on the other hand, the array can be sorted, shuffled, and so on, what value is it to show an image of a specific state in my code?

There's a reason we don't use symbolic representation of equations, and it has nothing to do with ASCII. It's because this is implemented on a processor that simulates a continuous value with a discrete value, which introduces all kinds of trade offs. We have a live thread on that now: why is aaaaaa not (aaa)(aaa). I need to be able to represent exactly how the computation is done. If I don't care, there is Mathematica, and and the like, to be sure.

If you disagree with me, please post your response in the form of an image. And then we will have a discussion with how powerful textual representation actually is. I'll use words, you use pictures. Be specific.

I'm not saying we should forsake language, if you look at the now very out of date Aurora demo, all the operations have sentence descriptions. This certainly isn't an all or nothing thing. If it makes sense to visualize some aspect of the system in a way that is meaningful to me, I should be able to do so - that is after all how people often solve hard problems.

Instead, I can just create a variable called AceSpades. It's not as... philosophical? but it's a million times more practical. Instead of needing an artist to come and draw up a new symbol for a concept I've created, I can just write it in text as a variable name. A lot of graphically based languages have been tried but they just don't scale to general problems. They work extremely well as limited languages for very constrained problems, but as soon as you need a new concept the complexity goes out the window compared to a traditional text based language. Why? Same reason as before - defining a concept in text is easier than designing a new symbol.

You touch on this in your blog too in how most of what programmers do is glue things together. You didn't really define what "glue things together" means though. I think it means "define new concepts using existing concepts". Eg, we take a MouseInput and a Sphere and create a new SphereSlice. With a text language we're just glueing the input library together with our geometry library. With a symbol based language, we have to actually define the new symbols and concepts of what a slice of a sphere is.

Even that might need a citation...

I don't think that needs a citation though. Any GUI is a graphical language for a constrained problem. I could use a generic text language to post this comment to HN, or I can use a specialized graphical language that provides me with this resizable text input box and reply button. It's extremely constrained in this case. If it had GUI elements for doing formatting, or the ability to post comments to other websites, it would be a less constrained graphical language. As you reduce constraints the graphical language would either need the ability to create new concepts or have many additional concepts predefined. So to answer your question about a citation: this very comment box is my citation. It works better than a purely text based input for submitting this comment.

Obviously for a general language you can't predefine all the required concepts which means they need to be user defined. User defining concepts in a graphical language is a difficult task as it requires creating uniquely human recognizable symbols for the new concepts.

You have two ways to get those new human recognizable symbols - you can generate them with an AI, or a human must generate them. AI is nowhere near able to generate symbols for concepts it doesn't understand as it would need to be a true AI with the ability to learn and understand new concepts. Having your graphical language's users define new concepts in effect makes those users into language designers. This is a bigger problem than it sounds as language design is an extremely difficult problem, and I personally don't want to be designing a language when I'm trying to solve a problem as I'll no doubt get the language design wrong if I'm focused more on the problem than the language design.

With that broad a definition (and I don't think it's horribly unreasonable), I agree it doesn't need a citation (even if I think GUIs are overapplied).

Edit: maybe graphical GUI editors such as in Xcode and Visual Studio could be considered tools for programming languages that are partially graphical and partially text based.

I will spot you that I won't natively know the language in question. In turn, I warn you that the most likely criticism I will make is that you've greatly increased the cognitive load of what I have to understand to understand your code without a corresponding payoff, even accounting for fluency in the vocabulary. (I say this not to be a jerk, but precisely to issue fair warning so you can head it off at the pass.) I will also spot fluency in your paradigm of choice... while I hope that the result is not a superficial syntax gloss on top of fold & map, I am happy to accept that I would need to know what those things are.

(I've come to start issuing the same challenge to anyone who thinks a visual programming language is the answer to our programming complexity problems, for instance. Don't draw me three boxes and two lines showing a simple map transform. Draw me something not huge, but nontrivial, say, the A-star algorithm. Then tell me it's better. Maybe it is, if you work on it enough, but don't scribble out the equivalent of "map (+1) [1, 2, 3]" and tell me you've "fixed" programming. Trivial's trivial in any representation.)

Take the card again. It's your example, after all. I cannot think of any way to use that to, say, write a small AI to play poker. I suppose I could see a use in a debugging situation for my 'hand' variable to display a little 5@ symbol (where @ is the suit symbol). But okay, let's think about that. What does it take to get that into the system?

No system 'knows' about cards. So I need a graphics designer to make a symbol for a card. I surely don't want an entire image of a card, because I have 20 other variables I am potentially interested in, which is why in this context a 5@ makes sense (like you would see in a bridge column in a newspaper). So somebody has to craft the art, we have to plug it into my dev sysstem, we need to coordinate it with the entire team, and so on. Then, it is still a very custom, one off solution. I use enums, you use ints, the python team is just using strings like "5H" - it goes on and on. I don't see a scalable solution here.

Well, I do see one scalable solution. It is called text. My debugger shows a textual depiction of my variable, and my wetware translates that. I'm a good reader, and I can quickly learn to read 54, "5H", FiveHearts as being the representation of that card. Will I visually "see" the value of a particular hand as quickly? Probably not, unless I'm working this code a lot. But I'll take that over firing up a graphics team and so on.

I do plenty of visualizations. It is a big reason for me using Python. If I want to write a Kalman filter, first thing I'm doing is firing up matplotlib to look at the results. But again, this is a custom process. I want to look at the noise, I want to look at the size of the kalman gain, I want to plot the filter output vs the covariance matrices, I want to.... program. Which I do textually, just fine, to generate the graphics I need.

I've dealt with data flow type things before. They are a royal pain. Oh, to start, it's great. Plop a few rectangles on the screen, connect with a few lines, and wow, you've designed a nand gate, or maybe a filter in matlab, or is it a video processing toolchain? Easy peasy. But when I need to start manipulating things programmatically it is suddenly a huge pain.

I am taking time out of writing an AI to categorize people based on what they are doing in a video (computer vision problem) to post this message. At a rudimentary level graphical display is great. It is certainly much easier for me to see my results displayed overlaid on the video, as opposed to trying to eyeball a JSON file or something. But to actually program this highly visual thing? I have never, ever heard anything but hand waving as to how I would do that in anything other than a textual way. I really don't think I would want to.

Anyway, scale things up in a way that I don't have to write so many matplotlib calls and you will have my attention. But I just haven't seen it. I've been programming since the early 80s, and graphical programming of some form or another has been touted as 'almost here'. Still haven't seen it, except in highly specialized disciplines, and I don't want to see it. "Pictures are worth a thousand words" because of compression. It's a PCA - distill a bunch of data down to a few dimensions. Sometimes I really want that, but not when programming, where all the data matters. I don't want a low order representation of my program.

I think this is the crux of the debate. The point isn't high quality visualizations, it's about bringing the simple little pictures you'd draw to solve your problem directly into the environment. Can you draw a box and put some text in it? Tada! Your own little representation of a card.

I'm not suggesting that you hire people out to build your representations :) This is about providing tools for understanding. Maybe you don't see value in that, and there's no reason you can't just keep seeing things as plain raw text (that's just a representation itself).

> Anyway, scale things up in a way that I don't have to write so many matplotlib calls and you will have my attention.

Give us a bit and I think we can provide a whole lot more than just that. But we'll see!

Something that I feel like is missing is the abstraction quality of programming. That is, the idea that I typically have very little use for a particular graphic when writing a program. I'm trying to express "whenever the user hits this button, flip over the top card in this set, move it over here, and then make the next card the top card" or whatever.

Some of Bret's demos look to me like he's thinking directly about this, and trying to discover where the abstraction fits in, and how direct manipulation can help to basically "see" that the abstraction is working. Perhaps that's a good guide to where direct manipulation could really help -- for anything relative complex, it's a big pain to see that code works. A direct manipulation system to basically flip through possibilities, especially into edge cases, and make sure they work as intended would definitely help out. I don't know whether that's the final way you want to express the system -- language is really powerful, even a million years later! -- but a way to see what the language does would be really awesome.

♠♣♥♦ × A23456789TJQK

If you need something more, vim has the "conceal" feature which can be used to replace (on the lines the cursor is not on) a given text with another (eg show ⟹ instead of =>). Would you be better off if there was an option to do this for variable/class/method names? I'm not sure.

If you use the short ⇒ to substitute for => (rather than long ⟹ as in your example), as well as many other Unicode symbols, then the overall code can be much shorter and thus more understandable.

The spec for the Fortress programming language made a point of not distinguishing between Unicode tokens in the program text and the ASCII keys used to enter them. Perhaps that's the best way to go?

I think we have a lot of experience to suggest otherwise.

Anyone who has had to maintain old Fortran or C code will likely know what I mean. With some early implementations limiting variable and function identifiers to 8 characters or less, we'd see a proliferation of short identifiers used. Such code is by far some of the hardest to work with due to variable and function names that are short to the point of being almost meaningless.

Then there are languages like APL and Perl, which make extensive use of symbols. APL has seen very limited use, and Perl code is well-known for suffering from maintenance issues unless extreme care is taken when initially creating the code.

Balance is probably best. We don't want excessively long identifiers like is often the case in Java, but we surely don't want excessively short ones, either.

Edited to add that I agree with your overall point. Shorter is not always clearer. It can be a benefit to have a few Unicode symbols displayed via 'conceal' but it's not (at least in my experience) a major productivity gain. And the number needs to be kept small. If I want Unicode symbol soup, I'll play a roguelike.

https://en.wikipedia.org/wiki/Unicode_Playing_Card_Block

Also it is probably good to remember that most of the good examples of doing this have probably already been done, debug visualizations in physics engines are a great example, a perfect way of showing incredibly complex data.

The only way to expand on that would be to add time and ease isolating a piece of data.

https://en.wikipedia.org/wiki/Constraint_programming

I think that's wrong. I think the reason we don't use symbolic representations is entirely due to a preference for ASCII. Whether relying on just the symbolic representation would be sufficient depends on domain - sometimes I don't care about the precise FP value (-ffast-math exists for a reason), maybe I'm working with bigints instead of floats, maybe ... But having the ability to specify and talk about the symbolic version seems only helpful - maybe some combination of static analysis and testing can make sure my implementation matches it?

Edited to add: Of course, whether it is helpful enough for the added difficulty specifying it with typical UI is another question.

I'm becoming a fan of the ideas espoused in eg http://www.vpri.org/pdf/m2009001_prog_as.pdf and http://shaffner.us/cs/papers/tarpit.pdf‎ where rather than trying to verify that arbitrary code matches your specification, you make the specification itself executable and then supply hints and heuristics on the most efficient way to execute it. It's a similar idea to first writing an sql query and then hinting which execution plan should be used. Compared to writing arbitrary code this approach limits expressiveness but it removes the verification problem entirely. So far we've only seen this approach used heavily in querying and in constraint solving. Luckily, it turns out that large chunks of the programs we write day to day can be expressed in terms of either database-style queries or constrained search (see eg http://boom.cs.berkeley.edu/).

Actually, the above is how I've been thinking about it for a while, but I'm not sure there's any reason we can't say "denotational constraints" as well - where exact denotation is just a particularly tight constraint.

   \integral{\integral nasty expresion dx}dy}

  (defun do-integrate (tree var)
      ;; -- do some crazy symbolic manipulation on the source tree
  )

  (defmacro integral (expr var)
     ,(do-integrate expr ,var))

People will bring up various symbolic and other specialized math packages. Sure enough, they exist. And, they are dog slow. They are used to explore problem spaces, and to get the solutions to small problems. But when it comes to it, we reach for C++, for Fortran (and now, maybe Julia) to get performant code. If I want to type equations and get results, why wouldn't I already be using one of those systems, heavily optimized for math computations of that sort? If I am in a general purpose language, it is because I need to specify the system in great detail, and obscuring it with symbols like sum and integrate just doesn't work.

And, in case the larger point is lost, this is an example to illustrate the larger case - that we can't really obscure large parts of the computational model. In cases where we can, we already do so. For example, I don't write my own red-black trees, I count on STL to do it for me. v.insert (make_pair("name", "Roger")) is a great abstraction (albeit verbose). But even when it comes to using something like BLAS & LAPACK, I have to choose the representation and so much more. Dense vs sparse, etc. So please don't retort with some integral or other math equation that can be solved efficiently with default methods - that misses the point. CS since the 50s has been a study of how to abstract concepts away, and have a done a fine job of it. A few pictures doesn't magically make the remaining problems disappear.

edit:

I somewhat know what I am talking about here. In my Ph.D program (left it, didn't graduate, not claiming a PhD) in the 80s my advisor was advocating an expert AI system to resolve these problems. Any guess as to the result of that research? The hint is that no expert system is built into any of our heavy math systems today. And just this week I sat through a session where a researcher was presenting early work he was doing no a DARPA grant to, wait for it, same thing, basically.

It's a outrageous, tremendously hard problem, and we keep getting people announcing that they have solved it, they just don't quite have the code running yet. Okay. Show me, don't tell me. A point-click interface to inject a sqrt symbol into my code, or an image of a playing card, is so far from the mark, both from the triviality of it, and the distance between that and a hard problem.

Part of programming is communicating thoughts. Plain text is great for that - we all read and write text. I also think it's easier to type "sqrt" or "sum", than to right-click, scroll through a pop-up menu and select the symbol I want. I suppose symbols can help one verify they've written what they intended if the environment supports translating "sqrt" and other functions into symbols that stretch over and around variables and other equations, but that's not what was demonstrated.

Finally, as others have pointed out, the mathematical expression of an algorithm doesn't necessarily lead to an efficient one.

And even if you have a graph it can still be stored in text format for version control reasons.

Coming from a mathematician with more than enough programming experience under his belt, programming is far more rigorous than mathematics. The reason nobody writes math in code is not because of ASCII, and it's not even because of the low-level hardware as someone else mentioned. It's because math is so jam-packed with overloaded operators and ad hoc notation that it would be an impossible feat to standardize any nontrivial subset of it. This is largely because mathematical notation is designed for compactness, so that mathematicians don't have to write down so much crap when trying to express their ideas. Your vision is about accessibility and transparency and focusing on problem solving. Making people pack and unpack mathematical notation to understand what their program is doing goes against all three of those!

So where is this coming from?

PS. I suppose you could do something like, have layovers/mouseovers on the typeset math that give a description of the variables, or something like that, but still sum(L) / len(L) is so much simpler and more descriptive than \sigma x_i / n

https://mitpress.mit.edu/sites/default/files/titles/content/...

Sometime the post not say: We want to make a program about everything. To make that possible, is necesary a way to express everything that could be need to be communicate. Words/Alphabet provide the best way.

In a normal language, when a culture discover something (let say, internet) and before don't exist words to describe internet-things then it "pop" from nowhere to existence. Write language have this ability in better ways than glyphs.

In programming, if we need a way to express how loop things, then will "pop" from nowhere that "FOR x IN Y" is how that will be.

Words are more flexible. Are cheap to write. Faster to communicate and cross boundaries.

But of course that have a Editor helper so a HEX value could be show as a color is neat - But then if a HEX value is NOT a color?, then you need a very strong type system, and I not see how build one better than with words.

To understand why programming remains hard it just takes a few minutes of working on a lower-level system, something that does a little I/O or has a couple of concurrent events, maybe an interrupt or two. I cannot envision a live system that would allow me to debug those systems very well, which is not to say current tools couldn't be improved upon.

One thing I've noticed working with embedded ARM systems is that we now have instruction and sometimes data trace debuggers that let us rewind the execution of a buggy program to some extent. The debugger workstations are an order of magnitude more powerful than the observed system so we can do amazing things with our trace probes. However, high-level software would need debugging systems an order of magnitude more powerful than the client they debug as well.

But the problem of being unobservable is harder. Literate programming might help in making chunks more accessible for understanding/replacing/toggling, but live flow forwards-backwards, it would not. But I have recently coded up an event library that logs the flow of the program nicely. Used appropriately, it probably could be used to step in and out as well.

I am not convinced that radical new tools are needed. We just have to be true to our nature as storytellers.

I find it puzzling why he talks about events as being problems. They seem like ideal ways of handling disjointed states. Isn't that how we organize our own ways?

I also find it puzzling to promote Excel's model. I find it horrendous. People have done very complex things with it which are fragile and incomprehensible. With code, you can read it and figure it out; literate programming helps this tremendously. But with something like Excel or XCode's interface builder, the structure is obscured and is very fragile. Spreadsheets are great for data entry, but not for programming-type tasks.

I think creation is rather easy; it is maintenance that is hard. And for that, you need to understand the code.

The Aurora demo did not look like a big improvement until maybe http://youtu.be/L6iUm_Cqx2s?t=7m54s where the TodoMVC demo beats even Polymer in LOC count and readability.

I've been thinking of similar new "programming" as the main computer UI, to ensure it's easy to use and the main UI people know. Forget Steve Jobs and XEROX, they threw out the baby with the bath water.

Using a computer is really calling some functions, typing some text input in between, calling some more.

Doing a few common tasks today is

  opening a web browser
  clicking Email
  reading some
  replying
  getting a reply back, possibly a notification

  clicking HN
  commenting on an article in a totally different UI than email
  going to threads tab manually to see any response
  

FaceTwitterEtsyRedditHN fiefdoms proliferate because of the separation between the XEROX GUI and calling a bunch of functions in Command Line. Siri and similar AI agents are the next step in simple UIs. What people really want to do is

  tell Dustin you don't agree with his assessment of Facebook's UI changes
  type/voice your disagreement
  share with public

  type it
  share message with Dustin and his circle of designers/hackers

  sentiment analysis of comments about Dustin's article compared to mine

Today's UI would involve going to a cute blog service because it has a proper visual template. This requires being one of the cool kids and knowing of this service. Then going to Goolge+ or email for the more private message. Then opening up an IDE or some text sentiment API and going through their whole other world of incantations.

Our glue/CRUD programming is a mess because using computers in general is a mess.

    def stddev(x):
        avg = sum(x)/len(x)
        return sqrt(sum((xi-avg)**2 for xi in x) / len(x))

    stddev xs = let avg = sum xs / length xs
                in sqrt $ sum [(x-avg)**2 | x <- xs] / length xs

    #include <valarray>
    #include <iostream>
    
    double standard_dev(const std::valarray<double> &vals)
    {
    	return sqrt(pow(vals - (vals.sum() / vals.size()), 2).sum() / vals.size());
    }
    
    int main()
    {
    	std::cout << standard_dev({2, 4, 4, 4, 5, 5, 7, 8}) << '\n';
    }

My personal opinion is that rather than trying to make programming more like math, we should make math more like programming - such that we stop assuming the reader has some magical knowledge needed to understand it.

Imagine an environment like a lisp machine, where all the code you run is open and available for you to inspect and edit. Imagine a vast indexed, cross-referenced, and mass-moderated collection of algorithm implementations and code snippets for every kind of project that's ever been worked on, at your fingertips.

Discussing how we might want slightly better ways to write and view the code we have written is ignoring the elephant problem- that everything you write has probably been written cleaner and more efficiently several times before.

If you don't think that's fucked up, think about this: The only reason to lock down your code is an economic one, despite that all the code being made freely usable would massively increase the total economic value of the software ecosystem.

in his body and his mind

That said, I think that fundamentally the problem isn't with programming, it's with US. :) Human beings are imprecise, easily confused by complexity, unable to keep more than a couple of things in mind at a time, can't think well in dimensions beyond 3 (if that), unable to work easily with abstractions, etc. Yet we're giving instructions to computers which are (in their own way) many orders of magnitude better at those tasks.

Short of AI that's able to contextually understand what we're telling them to do, my intuition is that the situation is only going to improve incrementally.

A byte is a convention over bits. An instruction is a convention over bytes. A programming language is a convention over instructions.

It turns out that every time someone sets out to solve a problem with programming, they create their own convention.

It just so happens that either there is no convetion over how to create covnentions, or it is just not followed and thus creates a paralel convention.

We cannot get our arbitrary conventions in line with each other, unless we plan in advance.

Considering, its amazing how far we have come in the middle of this chaos of unrestrained creation.

1: Why can't we use standard mathematical notation instead of strings of ASCII?

2: Why do we need lots of control flow and libraries when implementing a mathematical equation as an algorithm.

The first is simple: as others have pointed out here, math notation is too irregular and informal to make a programming language out of it.

The second is more important. In pretty much any programming language I can write:

    d = sqrt (b^2 - 4*a*c)

    x1 = (-b + d)/(2*a)

    x2 = (-b - d)/(2*a)

But in Haskell I can write this:

    stDev :: [Double] -> Double

    stDev xs = sqrt((1/(n-1)) * sum (map (\x -> (x-m)^2)) xs)

       where

          n = fromIntegral $ length xs

          m = sum xs / n

Experienced programmers will note that this is an inefficient implementation because it iterates over the list three times, which illustrates the other problem with using mathematics; the most efficient algorithm is often not the most elegant one to write down.

The truth is that programming is one of the most complex human undertakings by nature, and many of the difficulties faced by programmers - such as the invisible and unvisualizable nature of software - are intractable.

There are still no silver bullets.

http://en.wikipedia.org/wiki/No_Silver_Bullet http://faculty.salisbury.edu/~xswang/Research/Papers/SERelat...

As each new version of LT comes out I feel that it's suffering more and more from a clear lack of direction. And that makes me sad.

While in some cases that would be great, I'm not entirely sure more abstraction is what I want. Having a decent understanding of the different layers involved, from logic gates right up to high-level languages, has helped me tremendously as a programmer. For example, when writing in C, because I know some of the optimisations GCC makes, I know where to sacrifice efficiency for readability because the compiler will optimise it out anyway. I would worry that adding more abstraction will create more excuses not to delve into the inner workings, which wouldn't be to a programmer's benefit. Interested to hear thoughts on this!

To allow the everyday Joe to use simplified programming all the way down to machine code is a harder task. Languages like Haskell try to do it with an advanced compiler that can make enough sense of the high level language to generate efficient machine code.

Of course you'll still lose performance on some things compared to manual assembler but with larger programs advanced compilers often beat writing C/manual assembly.

Honestly the bigger performance problem is not wether you can make a high level language that generates perfect machine code but wether you can get through the politics/economics of JS/Obj-C/Java to distribute it.

A kind of obvious point on where having a knowledge of internals doesn't really help much is doing any kind of concurrent programming at scale. If you attempt to solve race conditions with the mindset of "knowing how the machine works", you end up inventing fences, mutexes, semaphores and monitors. (And OK, these are useful tools, and have been generally sufficient until recently - but they simply don't scale.) Compare this with something like Erlang's concurrency model - that of having many individual processes communicate through message passing (ie, the actor model), and it becomes much simpler to reason about concurrency (perhaps at the cost of efficiency, but as previously mentioned, that only matters in few cases). Erlang's model is abstract and says nothing about the machine on which it runs - and an existing knowledge of languages like C doesn't help a great deal to learning it over no programming experience at all.

Think of specialized being the antonym of of abstract, and consider that's what you are - a specialist - your skills are relevant for a specialized field, of implementing efficient programs on specific machines - but what OP wants to do is make programming available to anyone, as a general skill - he doesn't want everyone to become specialists at programming von-Neumann machines.

The sentiments expressed in the conclusion of Harel's article Statecharts in the Making: A Personal Account[3] really jumped out at me last year. When I read your blog post, I got the impression you are reaching related conclusions:

"If asked about the lessons to be learned from the statecharts story, I would definitely put tool support for executability and experience in real-world use at the top of the list. Too much computer science research on languages, methodologies, and semantics never finds its way into the real world, even in the long term, because these two issues do not get sufficient priority.

One of the most interesting aspects of this story is the fact that the work was not done in an academic tower, inventing something and trying to push it down the throats of real-world engineers. It was done by going into the lion's den, working with the people in industry. This is something I would not hesitate to recommend to young researchers; in order to affect the real world, one must go there and roll up one's sleeves. One secret is to try to get a handle on the thought processes of the engineers doing the real work and who will ultimately use these ideas and tools. In my case, they were the avionics engineers, and when I do biological modeling, they are biologists. If what you come up with does not jibe with how they think, they will not use it. It's that simple."

[1] http://www.wisdom.weizmann.ac.il/~harel/papers.html

[2] http://www.wisdom.weizmann.ac.il/~harel/papers/LiberatingPro...

[3] http://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.H...

> in order to affect the real world, one must go there and roll up one's sleeves

This has always been our strategy :) Whatever we do come up with, it will be entirely shaped by working with real people on coming up with something that actually solves the problem.

And even at the moment, the fact that so much of a typical program in the Wolfram Language is referentially transparent means its easy to pick something up out of your codebase and mess around with it, then put it back. That's a huge win over procedural languages.

But in terms of the language, many of the ideas Chris is talking about are already possible (and common) in the Wolfram Language:

It's functional and symbolic, so programs are all about applying transformations to data. In fact, the entire language is 'data', with the interesting side effect that some 'data' evaluates and rewrites itself (e.g. If).

The mathematical sum notation is unsurprisingly straightforward in WL.

And StandardForm downvalues allow for arbitrary visual display of objects in the frontend.

For example, the card would have a symbolic representation like PlayingCard["Spade", 1], but you could write

  StandardForm[PlayCard[suit_, n_]] := ImageCompose[$cardImages[suit], $cardNumbers[n]];

Graphics display as graphics, Datasets display as browseable hierarchical representations of their contents along with schema, etc...

I thought the `person.walk()` example, however, was misplaced. The whole point of encapsulation is to avoid thinking about internal details, so if you are criticizing encapsulation for hiding internal details you are saying that encapsulation never has any legitimate use.

I was left wondering if that was Chris's position, but convinced it couldn't be.

So I find myself getting "cold" and then coming back into it. The thing about taking a week to set up a dev environment is spot on. It's completely insane that it should take a week of work just to sit down and write a for-next loop or change a button's text somewhere.

The problem with programming is simple: it's full of programmers. So every damn little thing they do, they generalize and then make into a library. Software providers keep making languages do more -- and become correspondingly more complex.

When I switched to Ocaml and F# a few years ago, I was astounded at how little I use most of the crap clogging up my programming system. I also found that while writing an app, I'd create a couple dozen functions. I'd use a couple dozen more from the stock libraries. And that was it. 30-40 symbols in my head and I was solving real-world problems making people happy.

Compare that to the mess you can get into just getting started in an environment like C++. Crazy stuff.

There's also a serious structural problem with OOP itself. Instead of hiding complexity and providing black-box components to clients, we're creating semi-opaque non-intuitive messes of "wires". A lot of what I'm seeing people upset about in the industry, from TDD to stuff like this post, has its roots in OOP.

Having said all that and agreeing with the author, I'm a bit lost as to just what the heck he is ranting on about. I look forward to seeing more real tangible stuff -- I understand he's working on it. Best of luck.

I felt that the article takes a somewhat depressing view. Sure, these days we probably do all spend a lot of time getting two pieces of code written by others to work together. The article suggests there's no fun or creativity in that, but I find it plenty interesting. I see it as standing on the shoulders of giants, rather than just glumly fitting pipes together. It's the payoff of reusable code and modular systems. I happily use pre-made web servers, operating systems, network stack, code libraries etc. Even though it can be frustrating at times when things don't work, in the end my creations wouldn't even be possible without these things.

Turn the contrast down!

It seems like I can never win the contrast debate :p Try it now.

This is what I get from being married to a visual designer.

Or used black text on lighter background like most of the rest of the world.

I really liked this. But I think we're encoding work, not thought.

If I could add to the list of hard problems: cache invalidation, naming things, encoding things.

I think the problem in a lot of cases is that the language came first, then the problem/domain familiarity comes later. When your language lines up with your problem, it's just a matter of implementing the language. Your algorithms then don't change over time, just the quality of that DSL's implementation.

There will always be things we wish to say in our programs that in all known languages can only be said poorly.

Re graphics: A picture is worth 10K words - but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures.

Make no mistake about it: Computers process numbers - not symbols. We measure our understanding (and control) by the extent to which we can arithmetize an activity.

Thank you for all the work on Light Table, and I'm looking forward to seeing what the team does with Aurora.

* I'm not interested in your framework (even if it's not a framework) * so you've built another ORM just like many before you (even if there is no ORM inside it) * not interested in your language, I can get most of what I need writing comments in php (even if it's not remotely the same)

It takes a lot of time to transfer some of the ideas and benefits to the other side and no, you can't do it in a one minute pitch that average developer can relate to.

I'm more interested in programs that understand programs and their run-time characteristics. It'd be nice to query a system that could predict regressions in key performance characteristics based on a proposed change (something like a constraint propagation solver on a data-flow graph of continuous domains); even in the face of ambiguous type information. Something like a nest of intelligent agents that can handle the complexity of implementation issues in concert with a human operator. We have a lot of these tools now but they're still so primitive.

However, thinking about computation as only simple programs minimizes the opportunities in the opposite domain: using computation to supplement the inherently fragile and limited modeling that human brains can perform.

While presenting simplicity and understanding can help very much in realizing a simple mental model as a program, it won't help if the program being written is fundamentally beyond the capability of a human brain to model.

The overall approach is very valuable. Tooling can greatly assist both goals, but the tooling one chooses in each domain will vary greatly.

Things have not stayed stale for the past 20~30 years, in fact, state of programming have not stayed stale even in the recent 10 years.

We've been progressively solving problems we face, inventing tools, languages, frameworks to make our lives easier. Which further allows us to solve more complicated problems, or similar problems faster.

Problems we face now, like concurrency, big data, lack of cheap programmers to solve business problems were not even problems before, they are now, because they are possible now.

Once we solve those problems of today, we will face new problems, I don't know what they would be, but I am certain many of them would be problems we consider impractical or even impossible today.

Things that are technically hard and get a lot of hype. And maybe MVC/OOP/DI/TDD design patterns and agile.

The OP is promising something that's more of an architecture design issue like those of MVC libs. If he fails it will be because of a product design that doesn't catch on. It has no guarantee of catching on even if it's good. LISP and Haskell didn't. But their ideas trickle into other languages.

I suppose my general point is that things aren't stagnant, they are merely at a point where real progress tends to be hard-won and incremental. This may be frustrating to visionaries, but it seems both inevitable and perfectly fine to me.

So the marketing pivoted to being simple for MongoDB and being SSJS for Node. In Mongo's case scalability was severely hampered by the fundamental design, but many developers fell for the marketing and it cost them. Node.js can perform on some hello world benchmarks, but writing large scalable systems was a minefield of instability, callback hell bugs, lack of JS support for CPU intensive tasks, etc. It's still catching up to systems that existed in 2007.

The incremental improvement on scalability is nowhere to be seen. They do improve some other metric like programmer enthusiasm. Other newcomers did improve on easy scalability after more careful thought and years of effort but the hype machine largely left the topic.

A similar case can be made for HTML5/Flash promises for mobiles. You can use it but it often makes the process more difficult than writing two native apps in many cases. Good luck guessing which.

In many cases, it's the edge cases and feature creep that makes software genuinely terrible and by the time you layer in all that knowledge, it is a mess.

I don't care if you use VIM, EMACS, Visual Studio, or even some fancy graphical programming system. Complexity is complexity and managing and implementing that complexity is a complex thing.

Until we have tools to better manage complexity, we will have messes and the best tool to manage complexity are communication related, not software related.

I have a lot of respect for Chris. So, I hope I am wrong.

The article then compares some verbose C++ with a mathematical equation. That is hardly a fair comparison, the C++ code can be written and read by a human in a text editor, right click the equation > inspect element ... it's a gif. I loaded the gif into a text editor, it's hardcore gibberish.

Personally, I would stick with the verbose C++.

I really can't wait for programming to be more than just if statements and thinking about code as a grouping of ascii files and glueing libraries together. Things like Akka are nice steps in that direction.

i think abstraction may correllate with a ide or librarys usefulness, popularity, and development time, moreso than what your video demonstrates.

i have a question, how many clicks would getting this snippet from above to work?

you also have to navigate various dropdown menus? (dropdowns are pretty terrible UI, and i would think reading diff dropdown lists im not familar with would be jarring.) IMHO it would be like writing software with 2 mouse buttons, dropdowns or other visual elements, and instead of with keyboard, and would actually be slower. the opposite of my point above

    #include <valarray>
    #include <iostream>
    
    double standard_dev(const std::valarray<double> &vals)
    {
    	return sqrt(pow(vals - (vals.sum() / vals.size()), 2).sum() / vals.size());
    }
    
    int main()
    {
    	std::cout << standard_dev({2, 4, 4, 4, 5, 5, 7, 8}) << '\n';
    }

Doesn't help with the mathematical notation, though (Although it would be possible to do something about that, I suppose).

especially after I saw rich hickey's presentation "simple made easy" (my notes on it [1]).

I'm actually on a mission now to find ways to do things that are more straight forward. One of my finds is [2] 'microservices', which I think will resonate with how I perceive software these days.

[1] http://daemon.co.za/2014/03/simple-and-easy-vocabulary-to-de... [2] http://martinfowler.com/articles/microservices.html

This is a problem that many, many very smart people have spent careers on. Putting out a teaser post is brave and I have to believe you know what you are doing.

I am looking forward to the first taste. Do you have an ETA ?

The long term vision definitely does. At the moment we are mostly focused on building a good glue language. By itself it is already very capable for building CRUD apps and reactive UIs. If we can nail the tooling and make it as approachable as excel then that gives us a solid platform for more adventurous research.

We could do similar things to visualize actor systems, handle database manipulation and the like. The problem is that all we are really doing is asking for visualization aids that are only good at small things, and we have to build them, one at a time. Without general purpose visualizations, we need toolsets to build visualizations, which needs more tools. It's tools all the way down.

You can build tools for a narrow niche, just like the lispers just build their DSLs for each individual problem. But even in a world without a sea of silly parenthesis and a syntax that is built for compilers, not humans, under every single line of easy, readable, domain-centric code lies library code that is 100% incidental complexity, and we can't get rid of it.

Languages are hard. Writing code that attempts to be its own language is harder still. But those facts are not really the problem: They are a symptom. The real problem is that we are not equipped to deal with the detail we need to do our jobs.

Let's take, for instance, our carefree friends that want to build contracts on top of Bitcoin, by making them executable. I am sure a whole lot of people here realize their folly: The problem is that no problem that is really worth putting into a contract is well defined enough to turn it into code. We work with a level of ambiguity that our computers can't deal with. So what we are doing, build libraries on top of libraries, each a bit better, is about as good a job as we can do.

I do see how, for very specific domains, we can find highly reusable, visual high level abstractions. But the effort required to build that, with the best tools out there, just doesn't make any practical sense for a very narrow domain: We can build it, but there is no ROI.

I think the best we can do today is to, instead of concentrate so much on how shiny each new tool really is, to go back to the real basics of what makes a program work. The same things that made old C programs readable works just as well in Scala, but without half the boilerplate. We just have to forget about how exciting the new toys can be, or how smart they can make us feel, and evaluate them just on the basis of how can they really help us solve problems faster. Applying proper technique, like having code that has a narrative and consistent abstraction levels, will help us build tools faster, and therefore make it cheaper to, eventually, allow for more useful general purpose visualization plugins.