Today, the source code of a software project encodes *both* the design and the implementation of the app.
The design describes how the app looks, behaves and what it does (in theory).
The implementation is nothing more than a way of making the design a reality on a given platform. It uses known tools (CPU instructions arranged in a certain order, software libraries, programming languages, programming tools, etc.) to make the app real and working, rather than a design that is working only in someone's imagination.
Do you guys think it's a problem that source code encompasses both things? That they are inseparable, intertwined components?
I think so. Ideally, IMO, these two highly distinct concepts should be precisely that, distinct.
If I have a certain app that does something and looks a certain way, why should it matter what its implementation is? Why should it matter if I programmer A or programmer B wrote the implementation? Hell, the implementation might even be created by some sophisticated computer program.
The problem holding us back is... it's not easy. How do we represent design? Source code is a pretty good representation of implementation. But how do you represent design? It can reside in a designer's head, but that's not good enough. It can be scribbled on a piece of paper, or described in a lengthy design doc. But that's not good enough either, IMO. It has to be more dynamic, so that it can be linked up with a matching implementation and run on a computer/mobile device near you.
These are the right questions that we should be asking and trying to answer... IMO.
On Source Code, Design and Implementation
Well I was going to "Report" your thread, so it can be moved to the General Programming forum. However, it seems that the "Report" function is for thread that are truly negative. With that said, this is not a Lounge question, but a General Programming forum question. And should be moved to that forum, where it would be better served.
One could argue that the UI is the design and the code-behind (web or desktop) is the implementation of the design. You have software such as Windows Workflow Foundation that that tries to meld the design with the implementation. I'm sure by now that there is software that ties UML designs to the code itself. Basically presents a graphical tree/chart of your code and its flow. But it sounds like what you are describing is something similar to MVC (or similar paradigms).
Author
Fair enough. I didn't post it there because I thought it was too abstract for a forum like General Programming where real-world problems are being discussed, but I do want a programming-friendly audience to see it (hence GameDev.net).
Fair enough. I didn't post it there because I thought it was too abstract for a forum like General Programming where real-world problems are being discussed, but I do want a programming-friendly audience to see it (hence GameDev.net).
No, this is definitely General Programming forum material. That forum now handles Software Engineering and Practical Programming issues.
Today, the source code of a software project encodes *both* the design and the implementation of the app.
First, let's clarify exactly what you mean be "design," as that term can apply to a lot of things. Is the the UI design? Is it the workflow design? Is it the architectural design of the code? etc.
I'm going to assume you are aiming more at the UI design. I'd go with what Alpha_ProgDes said and say that what you want is probably something like a model-view-controller (MVC) design. It's entirely possible (and common) to design the UI (the view) using WYSIWYG or markup tools (i.e. without programming anything), implement a functional GUI-less back end that actually does all the work (the model) in some programming language, and glue the view and model together with a bit of code (the controller).
There have been several attempts to address this, with varying degrees of success. Most notable is obviously the web model.
And other technologies also follow the markup model, such as WPF/silverlight, XUL and QML.
And other technologies also follow the markup model, such as WPF/silverlight, XUL and QML.
If I have a certain app that does something and looks a certain way, why should it matter what its implementation is? Why should it matter if I programmer A or programmer B wrote the implementation? Hell, the implementation might even be created by some sophisticated computer program.[/quote]
You mean like how compilers generates machine code from human-readable source code? ;) In all seriousness, that's exactly what the whole concept of the separation between source code and machine code is for - just at a lower level than you're talking about.
So, what you're essentially proposing is some way to take the "design" of a program and produce a program from that, without worrying about what the implementation actually is, correct? Let's pretend that you've created some sophisticated design tool that lets designers specify a "design" and lets the computer figure out the "implementation". Since the "design" is now a direct specification of the program's look and behaviour, your "design" has now become the "implementation." So we're back at the beginning again.
I would say that if you're creating some sort of mechanism by which the design of a program is codified (which in my view is all that separates "design" from "ideas"), and the level of codification is sufficient that the machine can generate an implementation of the design for you, then all you're doing is creating a very high level programming language. In fact, I would say that a sufficiently formalized language intended for the design and specification of behaviour is the very definition of a programming language, no matter what medium it uses (textual in the case of traditional programming languages) and no matter what the compiled result is. Consequently, any design codified in that language is by definition "source code."
Author
[quote name='shurcool' timestamp='1343002840' post='4962087']
Today, the source code of a software project encodes *both* the design and the implementation of the app.
First, let's clarify exactly what you mean be "design," as that term can apply to a lot of things. Is the the UI design? Is it the workflow design? Is it the architectural design of the code? etc.[/quote]
By design I really mean everything about how the app looks, feels, and behaves. This includes the UI, of course, but also the behaviour. When you click on a button, or swipe something, the displayed pixels change in some fashion. This is all design in this context, basically everything that's "the front of the scene."
The implementation is everything that's behind the scenes, like the language that was used, the widget toolkit, the rendering API, the choice of sorting algorithm, etc.
What if we found some way to cleanly separate these two things, such that the implementation could be interchanged while keeping the design untouched. So a user wouldn't even notice any change from their perspective (aside from potentially increased performance, etc.).
One potential advantage of this is that the implementation stuff could be improved separately from the design, and reused across multiple projects. Kinda like libraries, I suppose.
Oberon_Command made some very good points. I have to keep thinking about this.
What if we found some way to cleanly separate these two things, such that the implementation could be interchanged while keeping the design untouched. So a user wouldn't even notice any change from their perspective (aside from potentially increased performance, etc.).
That's what the MVC architecture is all about. I don't know if I can go into much detail or not, so I won't go into too much, but take the company I work for, Sorenson Media, and our flagship product Squeeze, a video transcoding program. It's no secret we use Qt, but the key is that we are able to separate the GUI (everything you see and work with) from the transcoding engine (everything you don't see that actually transcodes the video). We can design the GUI, workflow, etc. in Qt designer. We can develop a separate GUI-less transcoding engine. Then it's just a matter of writing a little bit of glue code to connect the GUI to the transcoding engine, and walla, you have Squeeze Desktop. We just released version 8.5 recently, and while the GUI didn't change much, there were some significant backend changes made in the compression engine that allowed it to run up to 3x faster with some things. A user wouldn't realize the significant changes, because what they see and interact with is mostly the same. Alternatively, there were a few GUI and workflow changes that didn't require us to rewrite the engine, as they're separated.
Another benefit is that we can use the compression engine in other products of ours, like our cloud server, without booting up a GUI version of Squeeze Desktop.
Separating the front-end (what the user sees and interacts with) and the back-end (what actually does the work) is generally good practice, and there are several patterns and design architectures created specifically with that goal in mind. ChaosEngine noted some of the technologies that strive to make this easy.
I don't know how familiar you are with the MVC software design, but if you're not too familiar with it I suggest trying to get familiar with it by creating a program with C# + WPF or C++ + Qt (or whatever combo you may choose).
I think the really interesting question is what alternatives to the MVC software design exist, and what are good practices for separating the front-end from the back-end.
I suppose how you represent and design the front-end is a good enough question though. My answer would be: we can represent design with flowcharts documenting workflows, WYSIWYG editors for actual design and creating the GUI, markup languages for defining layout, etc. Then it's just a matter of gluing this to the code (in Qt, this is done with signals and slots), more or less.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
