It always amazed me that during their ~10 years of existence they never actually produced anything visible, other than demos. I remember I had been very excited about their "intentional" approach, even though so many years later I tend to think that it is actually an evolutionary dead-end (anyone remembers 4GL and 5GL languages? The late 90s when CASE tools and visual IDEs like Delphi were all the rage?). There is no silver bullet.
I'd love to be proven wrong, though, and hope to see some of the "intentional" stuff in any real software product.
I worked there for about a year, there were a number of contracts fulfilled using the workbench and associated technology (mostly NDA). At some point there was a pivot to a graphics-heavy reinterpretation of the core tech, which was pretty secretive and so didn't get a lot of press.
My project didn't use the core 'intentional' tech and we got spun off into an atrociously mismanaged, doomed sub-startup, so don't ask me too much about the intentsoft tech itself (though I can probably give rough answers for any high level stuff if you're curious).
I worked at Intentsoft in its earlier days (2006-2011) and left just as it was really starting to seriously staff up. I look at the pictures of the office these days and it's so surreal to me to see the absurd growth of what had stayed a small team for a really long time.
Is the Pole Position cabinet still there? Did anyone ever fix the monitor? I miss that thing.
They actually moved down the street from that original office about 2 and change years ago. This is around when I left, coincidentally, so it's hard to remember which cabinets made the trip or not.
I interviewed for the Intentional Programming group at Microsoft back in 1993! Their demo back then was amazing. I thought they'd have something out within a few years, and 24 years later I don't think anything commercial has come of it.
Like a lot of basic research, it's often others who sucseed at commercializing the innovation. And domain-specific-languages are an important tool today.
The late 90s when CASE tools and visual IDEs like Delphi were all the rage?). There is no silver bullet.
You seem to imply that Delphi was a fad that fell short of what it promised. On the contrary, it was incredibly productive. The reasons it has become a niche product have nothing to do with the validity of its features.
So if you are wondering why IS hasn't some product to show, it's not because the ideas are wrong, it's because tools are a very difficult area where execution is more important and readiness is all.
I suspect RAD/4GL will come back into fashion once someone gets a web version of it right. The current crop of tools aren't quite there, as they don't let you work outside the hard rails.
Google's "app maker" looks pretty close, but with issues around per user cost for some use cases. It does support freeform code, both client and server side, so no hard rails
https://developers.google.com/appmaker/
> Afterwards a couple of people said it was the most important demo they'd ever seen, comparing it even to the Mother of all Demos. For many there was a sense that the whole world of software development had just changed.
For the curious: it's difficult to find that particular demo on the web now, but the system didn't look too much different from its earlier incarnation at Microsoft in the '90s: https://www.youtube.com/watch?v=tSnnfUj1XCQ
There's a 2013 talk by Simonyi which talks about the workbench and enterprise use cases, but doesn't have screenshots, https://youtube.com/watch?v=4pT9tDmxjlg
I know it is not a fair comparison, but modern IDEs such as IntelliJ IDEA do pretty much everything demonstrated in this video. They build a database of the project, and let you do refactoring with the help of that.
The only thing that is notably missing from IDEA is the graphical representation: but raise your hand if you ever missed to see your program represented as a flowchart, for example. Does it actually have any real value? Perhaps, while you are learning programming.
The diagrams that are actually important and useful are mostly architecture diagrams and are impossible to create from source code - and it is also very hard to generate meaningful programs from architecture diagrams.
>The only thing that is notably missing from IDEA is the graphical representation: but raise your hand if you ever missed to see your program represented as a flowchart, for example.
(raises hand).
>Does it actually have any real value?
Yes.
>Perhaps, while you are learning programming.
Or when you're trying to understand the structure of a program you've just been assigned to work on, or that you wrote years ago and have to do a change, or when you want to see the big picture, etc etc.
Whenever I try to understand a program, I do draw structures of it. But it is NEVER the structure of the source code as is, but some parts the main flow with the unimportant bits left out (what is unimportant depends on the goal of the task at hand), mapped in some way that aligns with the goal of the investigation. It also has to include the runtime components, eg. objects, not classes.
I tried to use tools like Enterprise Architect in the past but failed to produce anything useful with them (that includes architecture diagrams - charts based on standards never seem to be fit for what I actually wanted to communicate).
The closest I ever got to usefulness was with database structures, we did manage to generate the actual production schema from ERwin for a SQL database at one place I worked, but of course, not the stored procedures.
>Whenever I try to understand a program, I do draw structures of it. But it is NEVER the structure of the source code as is, but some parts the main flow with the unimportant bits left out
While some tools might be more or less accommodating, there's nothing about visual representation per se that can't do that (including filtering the non-important parts, producing something akin to UML's interaction diagrams, etc).
I remember reading that, there was a bit of hype then around Domain Driven Design, domain modelling, and domain specific languages (DSLs). I had the impression Intentional was working on an uber DSL IDE or something. This sounds like they pivoted over to some sort of semantic web[1] scraper thing.
We'll probably see SSIS and Excel integration soon...
I respect what Simonyi did for the industry back in the day, but Intentional Software is just useless vaporware (or
-at best- weird academic research without practical applications).
As a Microsoft shareholder, I'm disappointed they're paying money for it (probably only to get Simonyi back, though his technical expertise is totally outdated and his management skills are questionable).
My introduction to intentional software was by way of the book "Generative Programming: Methods, Tools, and Applications" by Czarnecki and Eisenecker. I can't say that the book has had broad application to my engineering work, but it's been fun to think about from a philosophical perspective, bits like feature modeling have stuck, and even the early research into IP covered in the book impressed me...
What's the difference between Intentional's product and JetBrains' MPS? To me it seems like MPS can do much more and can accommodate Intentional's model as well. Anyone knows better?
It's hard to know. Intentional asks people who they show the product to, to sign a restrictive NDA, so they can't share what they do. I hope, after MS acquired them, they will release it under less restrictive license.
Research has shown that handwritten notes are more effective for learning and recall than typed notes, and for this reason pen computing will flourish whenever notetaking is required
Really? This smells like over-fitting the research to justify a desired commercial outcome.
It seems to me that the Hungarian notation is just a noisy code smell indicating that the type system is too primitive. With proper types the compiler can disallow illegal operations automatically. Why would you need Hungarian notation then?
You still need to name concepts. Hungarian notation is actually as much about communication as it is about code.
You'll get a lot of the benefits simply by being really disciplined about being consistent and precise with how you refer to things. What Hungarian does is force you to out of necessity.
This is true. We used Hungarian Notation internally extensively. The most counterintuitive thing is that having a cryptic name for a concept can have advantages: it has a precise meaning, and if you don't know what it is, you can't convince yourself that you do. If there's a class in my code called, I don't know, "View", that's going to give me clues as to what it is, but it may also mislead me into thinking it should support certain operations that it doesn't, or that we're talking about a UI view when actually it's referring to a database view, or whatever. If you just string together a handful of random letters, at least when communicating with someone else you know you're talking about the same thing, and you'll use the same name consistently.
Not a good idea for code that you want people to be able to use without gaining a deep understanding of, but for collaborating on inventing new things, it's a very effective communication hack.
For about three years I maintained the official internal coding conventions documentation for the Microsoft Word development team. This was when we were working on Office 2007. I remember loving the spirit of Hungarian notation. Using it in practice was also a major lesson and shaped my valuation of naming variables and types.
That same timeframe we ported Word's codebase from C to C++. That meant rewriting a bunch of manually ordered vtables for COM as regular virtual member functions on classes, and sadly, the elimination of anonymous unions from the codebase. But, type systems have really taken over and I think that's a good thing.
Because Word was written in C it followed a beautiful pattern of functions calling other functions all the way down. It treated data as data, and did not utilize classes or inheritance. I later came to understand the value of that way of thinking but at the time I thought it was so old fashioned. Of course, lacking the OO mindset meant that Word also lacked a great deal of encapsulation, and had horrible coupling across certain modules. Most notably, Undo, and Display.
> The most counterintuitive thing is that having a cryptic name for a concept can have advantages: it has a precise meaning, and if you don't know what it is, you can't convince yourself that you do.
To see complete and total saturation of that concept, take a look at the source code of Urbit
I can confirm this is roughly what the intentional source code looked like.
Personally I found it a huge pain and an unnecessary difficulty, but opinions differed :). The bigger problem was a lot of the code was crap (yay research code!). The lack of english names only made this more difficult because it removed valuable clues as to what the intention of the author might have been.
I'd love to be proven wrong, though, and hope to see some of the "intentional" stuff in any real software product.