ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi, I will try to be as less spammy as possible, so I will not insert the project name or links.
My team is designing a visual programming language, we are currently searching for people, both technical and nontechnical, that would like to see our design propositions, and give us opinions and critics.
The project is open source so we can't promise any monetary reward.
For applications and questions I will reply on this forum and on email: zauddelig - at - gmail - dot - com.
Yeah it is, we are currently in the design phase, so we want to meet people who wish to help us in this process.
Again we can't promise monetary rewards, but it is not that hard: every now and then we will ask you to review you something like 5 slides that should represent a sample, then you should say what is good, what is bad, what you would change and if you would use it. Obviously you will be able to refuse and we will erase your contact
We are planning to do it in a chat, so you will chat with me or with another team member.
However we are an association so if you want to have more responsibilities we will welcome you
Since you're using this forum, you should get a discussion started here about what you guys have so far. That way the input from forum members will help other members/viewers of this forum in addition to your group. Thanks!
We started the project codenamed ADjDaS not long over a month, even if the goal remain the same we had our initial idea heavily changed accordingly to the feedback we received thanks to the indiegogo campaign and to startup events.
As I've said we want it to be a community delivered product, so it would be good if as more as possible people collaborate to it; said that we are currently designing it, we decided that, before start coding, would be better to define a stable and agreed design.
The design is critical for this project because we want it to be a a language with an as easy as possible learning curve, while being a good choice even for a pro. The goal is to permit to anyone to develop the application that he is imagining, deploying it in as less time as possible even if he has no money.
Well we are not a big corporation (well, we are not a corp), it is a project from the bottom and we want to form a community for this project.
So I briefly looked at one of the links that unSpawn posted, and it looks like your goal is to develop a modular toolkit that non-programmers can use to create powerful applications. Is that accurate? If so, how do you plan to control computational complexity in cases where the "artist" designs an applications with major structural inefficiencies? I think that the limiting factor preventing non-programmers from writing powerful software isn't the difficulty of learning a language, but rather a lack of understanding of how to structure a program in an effective manner. As far as the reductionist approach, i.e. building a square from line segments, I think we can learn from the failure of neural networks to scale up to procedural computation (i.e. "reasoning reduces to neurons") due to the overwhelming computational complexity. In other words, reducing a system to its components obscures the importance of how those components fit together, which can often be the more challenging task.
OK, the major structural inefficiencies is a really hard to solve problem :-) .
I will start with this: Non-programmers have no idea of how a computers work, but to tell it plain simple even a lot of programmers have no idea of how their variables are registered on the computer physical memory (i.e. if their variables are pointers or something else)
Second since I'm not able to sustain it, I'm not going to mix myself in a neural networks debate, yet I can say that it is an open debate; however, while the app should represented as a graph or as a neural network, I'm not developing a neural network builder: the app is not a self learning app (that being the strong point of neural networks) so there is no need to constrain it with the neural networks limits.
Well the point is that we want to adopt an hybrid approach, non programmers should be able to start using pre-developed "pieces", but the "pieces" should be arbitrarily "complex" so that we can have cycles, conditional constructs and "procedural" pieces, you should be able to wrap and de-wrap the pieces to study and modify them. Wrapping means that there is the need to compile the app.
The goal is to create a "backward learning road" where the user can be productive from the start and highly performance and structure savvy at the end.
About the components fitting I don't get your point: would you be able to live in an house made randomly staking up a lot of building materials but without hammering a nail or something like it? The same is the valid for application, I don't think you would be able to use an application made randomly stacking up a lot of "pieces" without saying how they should fit together (well neural networks are an exception but that would be like living inside a tree, not that it is technically impossible: some engineers are actually designing it).
Being a somewhat hybrid solution the design is the most important phase, to prevent the birth of a nefarious product, we need to know in advance what the user experience should be like; accordingly to this we will put that on paper in natural language and formulas, defining the language syntax and semantics. Only after we have a good draft of this paper we will start to develop the language.
Fabrizio Messina
Last edited by zauddelig; 06-05-2013 at 06:43 AM.
Reason: minor changes
About the components fitting I don't get your point: would you be able to live in an house made randomly staking up a lot of building materials but without hammering a nail or something like it?
The point is that you can't give a person on the street a stack of wood and nails and expect a house to come out of it, because the structure of a house is a highly nontrivial thing. If you give someone with no knowledge of application construction a pile of components, you'll get exactly what you described; a stack of random components that doesn't add up to anything. My comment about the neural networks was related; at some level of aggregation you need to start using more sophisticated techniques than were used at lower levels to make everything fit together, otherwise the system will slowly grind to a halt. Having a vast array of complex components merely increases the size of the mess that can be created.
If the application developers will eventually learn some computer science then it might work out, but if the goal is to allow them to remain ignorant then I don't see that working out. If anything, beginners should start with the smaller components and work their way up to larger systems. For example, they might first learn to assemble the "atomic" components into simple applications, learn techniques to create effective larger applications, and eventually learn how to work with the internals of the atomic components and even create new ones. So, rather than outside-in it would be middle-out then middle-in.
The point is that you can't give a person on the street a stack of wood and nails and expect a house to come out of it, because the structure of a house is a highly nontrivial thing. If you give someone with no knowledge of application construction a pile of components, you'll get exactly what you described; a stack of random components that doesn't add up to anything. Having a vast array of complex components merely increases the size of the mess that can be created. If the secondary goal is to turn the non-programmers into programmers through this process, then I guess that could work out, though.
Kevin Barry
Ok the secondary goal is not so secondary, the non programmer should have at least the good will to learn the basics following one or two tutorials, here I'm saying that the language should be flexible and intuitive enough to be productive up from the start, this does not mean that the non programmer can compete with an experienced programmer.
Here should come the question "what do you mean with productive?" well this depend on the user, but I could say that "productive" is that, unless he want to do some strange or esoteric thing, he, the user, should be at least able to do a more or less simple working draft in less than a week (best case scenario) or in no more than two weeks (worst case scenario). Here I'm not saying that it should be a super speedy draft but a working one.
When he pass from the draft to a beta or a production ready one, I could say that the non programmer has grown into a programmer, I think that having a working draft and the possibility of visualize the app and its dead parts could sprint up the process.
You might want to treat MS Excel and MS Access as case studies of what not to do. Both have features that you describe (i.e. non-programmers can make effective tools somewhat quickly, and partially visually,) but tools built using both of those software systems degrade into garbage very quickly because it's so easy to get away with not knowing things that pertain to higher and lower levels of abstraction. Your work sounds much more thought out than either of those, but you should think about what makes them so ineffective for long-term use from the perspective of what they provide for the user to work with.
If people can get away with ignorance then they won't replace it with knowledge, especially if it's in a domain they consider themselves to be outside of. Here "get away with" merely means that the consequences of ignorance aren't severe enough to get them to move beyond where they are. This also applies to programmers, but presumably a non-programmer is less likely to want to learn the more formal aspects of software design because he/she is committed to an unrelated domain.
Well I cannot force the user to learn everything, and user must not be forced to do it. The user should be able to get away with as effortless as possible, obviously this cannot be an effortless process. On ms exel I've not used it consistently as I've used gnumerics but I think they are the same, while I did never use MS Access.
Well there are languages and languages, python for example is easy to learn and easy to good code with, while a language like php is much harder to learn and you mess up easily, I think that depends on the language characteristics and thought, and from its documentation.
This is the reason why me and my team prioritized the design of semantics and user experience to prevent the birth of a nefarious language, we are not super duper genial experts so we need to have people to help us do it, or rather I should say that we want to form a community.
Data design is another messy area of software development that often drives application structure and, more importantly, significantly contributes to project inertia. Have you considered how application data will be stored and transferred, or if data from applications using your framework will be usable by other applications? How will existing application data (e.g. documents) affect how the user modifies the application? Will they have to design the entire application up front just to prevent a premature document format from stifling development? In any case, you'll probably need some sort of complementary paradigm for data to go along with what you have in mind for process flow. When considering this, you'll need to decide if the users' applications will be maintaining data long term, of if the data the applications use will be static or have a shelf life.
I guess the common theme here is that you might want to come up with a well-defined scope of what your project is going to provide, what it isn't going to provide, what external resources it will provide access to, what it's intended to do well at, and what it's expected to do poorly at. After that, you can creatively fill in the space you've provided for yourself. It's better to define your own confines than to have them arise implicitly through the weaknesses of the design. In fact, it would be great if you could axiomatize a design style, then design your application framework using those axioms in such a way that your users also abide by those design axioms.
Well we will try to stay strict with the open standards as much as possible.
To make it simple it should be like latex, a latex document, say a pdf, is what the result of what do you mean in the tex file but does not retain anything of latex itself.
As latex compile in pdf or dvi or a number of other formats, we would like that it would theoretically be able to compile the same application in diverse forms, that is a web application or an application that use gtk/qt or even the shell (well I used graphical interface but it should be also be valid for all the parts of an application). Obviously the forms in which the applications will compile will depend on design choices, specialization and availability.
It is yet to define how the applications in the graph should communicate, id est "what is a complete universal information standard, through which send messages?", "an application should know about its caller or should only know about its arguments?", "how should wrapped application communicate and unwrapped ones?", "should wrapping concept stick up with the threading concept?", "what should control instances born and death?", etc.
As you can see a lot of questions arise from a single one, the bad news is these are open questions: there is not good or bad answer, but every one comes with pros and cons. Answered these you can know precisely what the language will be bad or good at. I have the urge to answer the question what it should be like.
Obviously these discussion are plain good for the project vitality and coherence
On axioms I think that you have a good point
Last edited by zauddelig; 06-06-2013 at 10:07 AM.
Reason: on axioms..
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.