I am considering the possibility of designing an application that would allow people to develop C++ code graphically. I was amazed when I discovered Scratch (see site and tutorial videos).
我正在考虑设计一个允许人们以图形方式开发C ++代码的应用程序的可能性。当我发现Scratch(参见网站和教程视频)时,我感到很惊讶。
I believe most of C++ can be represented graphically, with the exceptions of preprocessor instructions and possibly function pointers.
我相信大多数C ++都可以用图形表示,除了预处理器指令和可能的函数指针。
What C++ features do you think could be (or not be) represented by graphical items? What would be the pros and cons of such an application ? How much simpler would it be than "plain" C++?
您认为哪些C ++功能可以(或不是)由图形项表示?这种申请的利弊是什么?它比“普通”C ++简单多少?
RECAP and MORE:
RECAP和MORE:
Pros:
- intuitive
- simple for small applications
- helps avoid typos
适用于小型应用
有助于避免错别字
Cons:
- may become unreadable for large (medium?) - sized applications
- manual coding is faster for experienced programmers
- C++ is too complicated a language for such an approach
对于大型(中型)大小的应用程序可能变得不可读
对于有经验的程序员来说,手动编码更快
C ++对于这种方法来说太复杂了
Considering that we -at my work- already have quite a bit of existing C++ code, I am not looking for a completely new way of programming. I am considering an alternate way of programming that is fully compatible with legacy code. Some kind of "viral language" that people would use for new code and, hopefully, would eventually use to replace existing code as well (where it could be useful).
考虑到我们 - 我的工作 - 已经有相当多的现有C ++代码,我不是在寻找一种全新的编程方式。我正在考虑一种与遗留代码完全兼容的替代编程方式。人们会用于新代码的某种“病毒式语言”,并且希望它最终也会用来替换现有的代码(它可能有用)。
How do you feel towards this viral approach?
您如何看待这种病毒式方法?
When it comes to manual vs graphical programming, I tend to agree with your answers. This is why, ideally, I'll find a way to let the user always choose between typing and graphical programming. A line-by-line parser (+partial interpreter) might be able to convert typed code into graphical design. It is possible. Let's all cross our fingers.
说到手动和图形编程,我倾向于同意你的答案。这就是为什么理想情况下,我会找到一种方法让用户总是在打字和图形编程之间做出选择。逐行解析器(+部分解释器)可能能够将类型化代码转换为图形设计。有可能的。让我们全都交叉。
Are there caveats to providing both typing and graphical programming capabilities that I should think about and analyze carefully?
是否有提供打字和图形编程功能的警告我应该仔细考虑和分析?
I have already worked on template classes (and more generally type-level C++) and their graphical representation. See there for an example of graphical representation of template classes. Boxes represent classes or class templates. First top node is the class itself, the next ones (if any) are typedef instructions inside the class. Bottom nodes are template arguments. Edges, of course, connect classes to template arguments for instantiations. I already have a prototype for working on such type-level diagrams.
我已经处理过模板类(更常见的是类型级C ++)及其图形表示。在那里查看模板类的图形表示的示例。框表示类或类模板。第一个*节点是类本身,下一个节点(如果有的话)是类中的typedef指令。底部节点是模板参数。当然,边缘将类连接到实例化的模板参数。我已经有了处理这种类型级图表的原型。
If you feel this way of representing template classes is plain wrong, don't hesitate to say so and why!
如果您觉得这种表示模板类的方式是完全错误的,请不要犹豫,为什么这么说!
11 个解决方案
#1
6
Writing code is the easiest part of a developers day. I don't think we need more help with that. Reading, understanding, maintaining, comparing, annotating, documenting, and validating is where - despite a gargantuan amount of tools and frameworks - we still are lacking.
编写代码是开发人员日最容易的部分。我认为我们不需要更多的帮助。阅读,理解,维护,比较,注释,记录和验证是在哪里 - 尽管有大量的工具和框架 - 我们仍然缺乏。
To dissect your pros:
剖析你的专业人士:
Intuitive and simple for small applications - replace that with "misleading". It makes it look simple, but it isn't: As long as it is simple, VB.NET is simpler. When it gets complicated, visual design would get in the way.
对于小型应用程序而言直观且简单 - 用“误导性”代替。它使它看起来很简单,但事实并非如此:只要它很简单,VB.NET就更简单了。当它变得复杂时,视觉设计会妨碍你。
Help avoid typos - that's what a good style, consistency and last not least intellisense are for. The things you need anyway when things aren't simple anymore.
帮助避免拼写错误 - 这就是一个好的风格,一致性和最后的智力感知。当事情不再简单时,你需要的东西。
Wrong level
You are thinking on the wrong level: C++ statements are not reusable, robust components, they are more like a big bag of gears that need to be put together correctly. C++ with it's complexity and exceptions (to rules) isn't even particulary suited.
您正在考虑错误的级别:C ++语句不是可重用的,强大的组件,它们更像是需要正确组合的大包装齿轮。 C ++的复杂性和异常(对于规则)甚至不是特别适合。
If you want to make things easy, you need reusable components at a much higher level. Even if you have these, plugging them together is not simple. Despite years of struggle, and many attempts in many environments, this sometimes works and often fails.
如果您想简化操作,则需要更高级别的可重用组件。即使你有这些,将它们插在一起并不简单。尽管经历了多年的努力,并且在许多环境中进行了许多尝试,但这有时会起作用并且经
Viral - You are correct IMO about that requriement: allow incremental adoption. This is closely related to switching smoothly between source code and visual representation, which in turn probably means you must be able to generate the visual representation from modified source code.
病毒 - 你是关于这个要求的正确的IMO:允许逐步采用。这与在源代码和可视化表示之间平滑切换密切相关,这反过来可能意味着您必须能够从修改后的源代码生成可视化表示。
IDE Support - here's where most language-centered approaches go astray. A modern IDE is more than just a text editor and a compiler. What about debugging your graph - with breakpoints, data inspection etc? Will profilers, leak detectors etc. highlight nodes in your graph? Will source control give me a Visual Diff of yesterday's graph vs. today's?
IDE支持 - 这是大多数以语言为中心的方法误入歧途的地方。现代IDE不仅仅是文本编辑器和编译器。如何调试图表 - 使用断点,数据检查等?轮廓仪,检漏仪等会突出显示图表中的节点吗?源代码控制会给我一个昨天的图形与今天的视觉差异吗?
Maybe you are on to something, despite all my "no"s: a better way to visualize code, a way to put different filters on it so that I see just what I need to see.
也许你正在做一些事情,尽管我的所有“不”:一种更好的方法来可视化代码,一种在其上放置不同过滤器的方法,以便我看到我需要看到的东西。
#2
9
Much as I like Scratch, it is still much quicker for an experienced programmer to write code using a text editor than it is to drag blocks around, This has been proved time and again with any number of graphical programming environments.
就像我喜欢Scratch一样,对于有经验的程序员来说,使用文本编辑器编写代码比使用文本编辑器编写代码要快得多,这已经在任何数量的图形编程环境中一次又一次地得到证明。
#3
5
The early versions of C++ were originally written so that they compiled to C, then the C was compiled as normal.
最初编写C ++的早期版本,以便它们编译为C,然后C编译为正常。
What it sounds like you are describing is a graphical language that is compiled to C++, which will then be compiled as normal.
你所描述的是一种编译成C ++的图形语言,然后将被正常编译。
So really you are not creating a graphical C++, you are creating a new language that happens to be graphical. Nothing wrong with that, but don't let C++ restrict what you do, because eventually you may want to compile the graphical language straight to machine code, or even to something like CIL, Java ByteCode, or whatever else tickles your fancy.
所以你真的没有创建一个图形化的C ++,你正在创建一个恰好是图形化的新语言。这没有什么不对,但是不要让C ++限制你做的事情,因为最终你可能想要将图形语言直接编译为机器代码,甚至是像CIL,Java ByteCode或其他任何你喜欢的东西。
Other graphical languages you may want to check out are LabVIEW, and more generally the category of visual programming languages.
您可能想要查看的其他图形语言是LabVIEW,更常见的是可视化编程语言的类别。
Good luck in your efforts.
祝你好运。
#4
2
The complexity of a nontrivial program is usually too high to be represented with graphical symbols, which are low in their information content. Unless your approach is markedly different in some way, I am skeptical that this would be of value based on past efforts.
非平凡程序的复杂性通常太高而无法用图形符号表示,图形符号的信息内容很少。除非你的方法在某种程度上有明显的不同,否则我怀疑这将基于过去的努力是有价值的。
So, practically speaking, his will be useful only for instructional purposes and very simple programs. But that would still be a great target market for a product like this. sometimes people have trouble grasping the fundamentals, and a visual model might be just the thing to help things click.
所以,实际上,他只会用于教学目的和非常简单的程序。但对于像这样的产品来说,这仍然是一个很好的目标市场。有时人们很难掌握基础知识,视觉模型可能只是帮助点击的东西。
#5
1
Interesting idea. I doubt I'd use it though. I tend to prefer coding in a flat text editor, not even an IDE, and for tough problems I prefer a pad of paper. Most of the really experienced programmers I know work this way, Maybe it's because we grew up in a different environment, but I think it's also because of the way we think about programming. As you get more experience, you start seeing the code in your head more clearly than any GUI tool will show it to you.
有趣的想法。我怀疑我会用它。我更喜欢在平面文本编辑器中编码,甚至不喜欢IDE,而对于棘手的问题,我更喜欢纸垫。我认识的大多数真正有经验的程序员都是这样工作的,也许是因为我们在不同的环境中长大,但我认为这也是因为我们对编程的看法。随着您获得更多经验,您可以比任何GUI工具更清楚地看到您头脑中的代码。
As for your question, I'd nominate templates as one of the harder / more interesting sort of thing to try to represent well. They are ubiquitous and carry information that you won't have access to as you are designing your tool. Getting that to the user in a useful way should pose an interesting challenge.
至于你的问题,我提名模板作为试图表现得更好的更难/更有趣的事情之一。它们无处不在,并且随身携带您在设计工具时无法访问的信息。以有用的方式向用户提供这应该是一个有趣的挑战。
#6
1
What C++ features do you think could be [...] represented by graphical items?
您认为哪些C ++功能可以由图形项表示?
Object Oriented Design. Hence classes, inheritance, polymorphism, mutability, const-ness etc. And, templates.
面向对象设计。因此,类,继承,多态,可变性,常量等,以及模板。
What would be the pros and cons of such an application?
这种申请的利弊是什么?
It may be easier for beginners to start writing programs. For the experienced, it may be get rid of the boring parts of programming.
初学者可能更容易开始编写程序。对于经验丰富的人来说,它可能会摆脱编程的枯燥部分。
Think of any other code generator. They create a framework for you to write the more involved portion(s). They also lead to bloated-code (think of any WYSIWYG HTML editor).
想想任何其他代码生成器。他们为您创建了一个框架,用于编写涉及更多的部分。它们还会导致膨胀代码(想想任何WYSIWYG HTML编辑器)。
The biggest challenge, as I see it, is that any such UI necessarily hinders the user's imagination.
正如我所看到的,最大的挑战是任何这样的UI都必然会妨碍用户的想象力。
How much simpler would it be than "plain" c++ ?
它比“普通”的c ++简单多少?
It can be a real pain, when you wade through truckloads of errors which is typical of code generators.
当你通过代码生成器的典型错误消耗时,这可能是一个真正的痛苦。
Further, since a lot of code is generated, you have no idea of what is going on -- debugging becomes difficult.
此外,由于生成了大量代码,因此您不知道发生了什么 - 调试变得困难。
Also, for the experienced there may be some irritation to find that the generated code is not per their preferred coding style.
此外,对于有经验的人来说,发现生成的代码不符合他们喜欢的编码风格可能会有些恼怒。
#7
1
I prefer hot-keys instead graphical menus and buttons.
And I think same thing will happen with graphical development tool. Many peoples will prefer manual codding.
我更喜欢热键而不是图形菜单和按钮。我认为图形开发工具也会发生同样的事情。许多人都喜欢手工编码。
But, source code visualizer - should be nice thing.
但是,源代码可视化器 - 应该是件好事。
#8
1
I like the idea, but I suspect there comes a point where things get far too complicated to be represented graphically.
我喜欢这个想法,但我怀疑有些事情变得太复杂而无法用图形表示。
However, given recent experience at work; it would be useful to give such a graphical interface to a non-techie person to use to create basic drag-and-drop programs, leaving myself free to get on with some "proper" programming ;-) If it can do the job of allowing somebody non-skilled to build something functional it can be a very good thing (even if programming logic escapes them)
但是,鉴于最近的工作经验;给非技术人员提供这样一个图形界面用于创建基本的拖放程序,让我*地继续进行一些“正确的”编程会很有用;-)如果它可以完成的工作允许某些非技术人员构建功能性的东西,这可能是一件非常好的事情(即使编程逻辑逃脱它们)
There comes a point in such a system where it becomes easier to define what you want to do using literal C++ code, rather than have a user interface getting in the way; it can get frustrating to the sessioned programmer knowing the precise code that needs to be written but then only being limited to the design GUI. I'm specifically thinking about a more common application, such as html editors/designers in which they allow newbies to build their websites without knowing any html at all.
在这样的系统中有一点,使用文字C ++代码更容易定义您想要做的事情,而不是让用户界面妨碍;对于会话程序员来说,知道需要编写的精确代码然后仅限于设计GUI会让他感到沮丧。我特别想到一个更常见的应用程序,例如html编辑器/设计器,它们允许新手在不知道任何html的情况下构建他们的网站。
It would be interesting to see how such a system would handle the dynamic allocation of memory, and the different states of a program as time progressed; I suspect that there are some very basic programming concepts that may be difficult to represent graphically.. Polymorphism..? Virtual Classes, LinkList, Stacks/Circular Queues. I wonder for a moment how you would explain an image compression algorithm (such as jpg) successfully too without the help of a gigantic display screen.
看看这样一个系统如何处理内存的动态分配,以及随着时间的推移程序的不同状态,将会很有趣;我怀疑有一些非常基本的编程概念可能难以用图形表示..多态性..?虚拟类,链接列表,堆栈/循环队列。我想知道如何在没有巨大显示屏的帮助下成功解释图像压缩算法(如jpg)。
I also wonder if such a system would even go to such a low level, and whether you would be dealing with abstracted concepts and the compiler would be working out the best way to do something.
我也想知道这样的系统是否会达到如此低的水平,以及你是否会处理抽象的概念,编译器会找出最好的方法来做某事。
#9
1
I've been working on a new model-driven software development paradigm named ABSE (http://www.abse.info) that supports end-user programming: It's a template-based system that can be complemented with transformation code. I also have an IDE (named AtomWeaver) implementing ABSE that is in pre-alpha stage right now.
我一直在研究一种名为ABSE(http://www.abse.info)的新模型驱动软件开发范例,它支持最终用户编程:它是一个基于模板的系统,可以用转换代码进行补充。我还有一个IDE(名为AtomWeaver),它实现了现在处于pre-alpha阶段的ABSE。
With AtomWeaver, as an expert/architect, you build your knowledge Templates, and then the developers (or end-users if you make your meta-models simpler) can just "assemble" systems by building blocks, and then filling template parameters in form-style editors.
使用AtomWeaver,作为专家/架构师,您可以构建知识模板,然后开发人员(或最终用户,如果您使元模型更简单)可以通过构建块“组装”系统,然后填写表单中的模板参数风格的编辑。
At the end, pressing the "Generate" button will create the final system as specified by the architect/expert.
最后,按“生成”按钮将创建建筑师/专家指定的最终系统。
#10
0
I'm surprised you think function pointers would be a particular problem. How about anything at all to do with pointers?
我很惊讶你认为函数指针会成为一个特殊的问题。如何处理指针呢?
A programming language can be represented by a hierarchy of nodes - that's exactly what the compiler turns it into. It is very strange that the UI for editing programs is still a sequence of characters that get parsed, because the degrees of freedom in the editor is way larger than the available set of allowed choices. But intellisense helps to reduce this problem a lot.
编程语言可以由节点层次结构表示 - 这正是编译器将其转换为的结构。用于编辑程序的UI仍然是一系列被解析的字符,这是非常奇怪的,因为编辑器中的*度大于可用的允许选择集。但intellisense有助于减少这个问题。
C++ would be a strange choice to base such a system on.
基于这样的系统,C ++将是一个奇怪的选择。
#11
0
I think the major problem of this kind of IDEs are that the code generated becomes unmantainable easily.
我认为这种IDE的主要问题是生成的代码很容易变得难以理解。
This happened to Delphi. It's a really nice tool to develop some kind of applications, however, when we start adding complex relationships between the components, start adding Design Patterns, etc. the code grows to an unmantainable size.
这发生在德尔福。这是开发某种应用程序的一个非常好的工具,但是,当我们开始在组件之间添加复杂关系,开始添加设计模式等时,代码会增长到不可比较的大小。
I believe it's also because graphical tools don't apply the concept of MVC (or if they do, it's only in the way that the IDE understands).
我相信这也是因为图形工具不应用MVC的概念(或者如果它们这样做,它只是以IDE理解的方式)。
It can be really helpful for prototypes and very small applications that don't tend to grow, otherwise it can become a mess for the developer(s)
对于原型和非常小的不易增长的应用程序来说它真的很有用,否则它会成为开发人员的一团糟。
#1
6
Writing code is the easiest part of a developers day. I don't think we need more help with that. Reading, understanding, maintaining, comparing, annotating, documenting, and validating is where - despite a gargantuan amount of tools and frameworks - we still are lacking.
编写代码是开发人员日最容易的部分。我认为我们不需要更多的帮助。阅读,理解,维护,比较,注释,记录和验证是在哪里 - 尽管有大量的工具和框架 - 我们仍然缺乏。
To dissect your pros:
剖析你的专业人士:
Intuitive and simple for small applications - replace that with "misleading". It makes it look simple, but it isn't: As long as it is simple, VB.NET is simpler. When it gets complicated, visual design would get in the way.
对于小型应用程序而言直观且简单 - 用“误导性”代替。它使它看起来很简单,但事实并非如此:只要它很简单,VB.NET就更简单了。当它变得复杂时,视觉设计会妨碍你。
Help avoid typos - that's what a good style, consistency and last not least intellisense are for. The things you need anyway when things aren't simple anymore.
帮助避免拼写错误 - 这就是一个好的风格,一致性和最后的智力感知。当事情不再简单时,你需要的东西。
Wrong level
You are thinking on the wrong level: C++ statements are not reusable, robust components, they are more like a big bag of gears that need to be put together correctly. C++ with it's complexity and exceptions (to rules) isn't even particulary suited.
您正在考虑错误的级别:C ++语句不是可重用的,强大的组件,它们更像是需要正确组合的大包装齿轮。 C ++的复杂性和异常(对于规则)甚至不是特别适合。
If you want to make things easy, you need reusable components at a much higher level. Even if you have these, plugging them together is not simple. Despite years of struggle, and many attempts in many environments, this sometimes works and often fails.
如果您想简化操作,则需要更高级别的可重用组件。即使你有这些,将它们插在一起并不简单。尽管经历了多年的努力,并且在许多环境中进行了许多尝试,但这有时会起作用并且经
Viral - You are correct IMO about that requriement: allow incremental adoption. This is closely related to switching smoothly between source code and visual representation, which in turn probably means you must be able to generate the visual representation from modified source code.
病毒 - 你是关于这个要求的正确的IMO:允许逐步采用。这与在源代码和可视化表示之间平滑切换密切相关,这反过来可能意味着您必须能够从修改后的源代码生成可视化表示。
IDE Support - here's where most language-centered approaches go astray. A modern IDE is more than just a text editor and a compiler. What about debugging your graph - with breakpoints, data inspection etc? Will profilers, leak detectors etc. highlight nodes in your graph? Will source control give me a Visual Diff of yesterday's graph vs. today's?
IDE支持 - 这是大多数以语言为中心的方法误入歧途的地方。现代IDE不仅仅是文本编辑器和编译器。如何调试图表 - 使用断点,数据检查等?轮廓仪,检漏仪等会突出显示图表中的节点吗?源代码控制会给我一个昨天的图形与今天的视觉差异吗?
Maybe you are on to something, despite all my "no"s: a better way to visualize code, a way to put different filters on it so that I see just what I need to see.
也许你正在做一些事情,尽管我的所有“不”:一种更好的方法来可视化代码,一种在其上放置不同过滤器的方法,以便我看到我需要看到的东西。
#2
9
Much as I like Scratch, it is still much quicker for an experienced programmer to write code using a text editor than it is to drag blocks around, This has been proved time and again with any number of graphical programming environments.
就像我喜欢Scratch一样,对于有经验的程序员来说,使用文本编辑器编写代码比使用文本编辑器编写代码要快得多,这已经在任何数量的图形编程环境中一次又一次地得到证明。
#3
5
The early versions of C++ were originally written so that they compiled to C, then the C was compiled as normal.
最初编写C ++的早期版本,以便它们编译为C,然后C编译为正常。
What it sounds like you are describing is a graphical language that is compiled to C++, which will then be compiled as normal.
你所描述的是一种编译成C ++的图形语言,然后将被正常编译。
So really you are not creating a graphical C++, you are creating a new language that happens to be graphical. Nothing wrong with that, but don't let C++ restrict what you do, because eventually you may want to compile the graphical language straight to machine code, or even to something like CIL, Java ByteCode, or whatever else tickles your fancy.
所以你真的没有创建一个图形化的C ++,你正在创建一个恰好是图形化的新语言。这没有什么不对,但是不要让C ++限制你做的事情,因为最终你可能想要将图形语言直接编译为机器代码,甚至是像CIL,Java ByteCode或其他任何你喜欢的东西。
Other graphical languages you may want to check out are LabVIEW, and more generally the category of visual programming languages.
您可能想要查看的其他图形语言是LabVIEW,更常见的是可视化编程语言的类别。
Good luck in your efforts.
祝你好运。
#4
2
The complexity of a nontrivial program is usually too high to be represented with graphical symbols, which are low in their information content. Unless your approach is markedly different in some way, I am skeptical that this would be of value based on past efforts.
非平凡程序的复杂性通常太高而无法用图形符号表示,图形符号的信息内容很少。除非你的方法在某种程度上有明显的不同,否则我怀疑这将基于过去的努力是有价值的。
So, practically speaking, his will be useful only for instructional purposes and very simple programs. But that would still be a great target market for a product like this. sometimes people have trouble grasping the fundamentals, and a visual model might be just the thing to help things click.
所以,实际上,他只会用于教学目的和非常简单的程序。但对于像这样的产品来说,这仍然是一个很好的目标市场。有时人们很难掌握基础知识,视觉模型可能只是帮助点击的东西。
#5
1
Interesting idea. I doubt I'd use it though. I tend to prefer coding in a flat text editor, not even an IDE, and for tough problems I prefer a pad of paper. Most of the really experienced programmers I know work this way, Maybe it's because we grew up in a different environment, but I think it's also because of the way we think about programming. As you get more experience, you start seeing the code in your head more clearly than any GUI tool will show it to you.
有趣的想法。我怀疑我会用它。我更喜欢在平面文本编辑器中编码,甚至不喜欢IDE,而对于棘手的问题,我更喜欢纸垫。我认识的大多数真正有经验的程序员都是这样工作的,也许是因为我们在不同的环境中长大,但我认为这也是因为我们对编程的看法。随着您获得更多经验,您可以比任何GUI工具更清楚地看到您头脑中的代码。
As for your question, I'd nominate templates as one of the harder / more interesting sort of thing to try to represent well. They are ubiquitous and carry information that you won't have access to as you are designing your tool. Getting that to the user in a useful way should pose an interesting challenge.
至于你的问题,我提名模板作为试图表现得更好的更难/更有趣的事情之一。它们无处不在,并且随身携带您在设计工具时无法访问的信息。以有用的方式向用户提供这应该是一个有趣的挑战。
#6
1
What C++ features do you think could be [...] represented by graphical items?
您认为哪些C ++功能可以由图形项表示?
Object Oriented Design. Hence classes, inheritance, polymorphism, mutability, const-ness etc. And, templates.
面向对象设计。因此,类,继承,多态,可变性,常量等,以及模板。
What would be the pros and cons of such an application?
这种申请的利弊是什么?
It may be easier for beginners to start writing programs. For the experienced, it may be get rid of the boring parts of programming.
初学者可能更容易开始编写程序。对于经验丰富的人来说,它可能会摆脱编程的枯燥部分。
Think of any other code generator. They create a framework for you to write the more involved portion(s). They also lead to bloated-code (think of any WYSIWYG HTML editor).
想想任何其他代码生成器。他们为您创建了一个框架,用于编写涉及更多的部分。它们还会导致膨胀代码(想想任何WYSIWYG HTML编辑器)。
The biggest challenge, as I see it, is that any such UI necessarily hinders the user's imagination.
正如我所看到的,最大的挑战是任何这样的UI都必然会妨碍用户的想象力。
How much simpler would it be than "plain" c++ ?
它比“普通”的c ++简单多少?
It can be a real pain, when you wade through truckloads of errors which is typical of code generators.
当你通过代码生成器的典型错误消耗时,这可能是一个真正的痛苦。
Further, since a lot of code is generated, you have no idea of what is going on -- debugging becomes difficult.
此外,由于生成了大量代码,因此您不知道发生了什么 - 调试变得困难。
Also, for the experienced there may be some irritation to find that the generated code is not per their preferred coding style.
此外,对于有经验的人来说,发现生成的代码不符合他们喜欢的编码风格可能会有些恼怒。
#7
1
I prefer hot-keys instead graphical menus and buttons.
And I think same thing will happen with graphical development tool. Many peoples will prefer manual codding.
我更喜欢热键而不是图形菜单和按钮。我认为图形开发工具也会发生同样的事情。许多人都喜欢手工编码。
But, source code visualizer - should be nice thing.
但是,源代码可视化器 - 应该是件好事。
#8
1
I like the idea, but I suspect there comes a point where things get far too complicated to be represented graphically.
我喜欢这个想法,但我怀疑有些事情变得太复杂而无法用图形表示。
However, given recent experience at work; it would be useful to give such a graphical interface to a non-techie person to use to create basic drag-and-drop programs, leaving myself free to get on with some "proper" programming ;-) If it can do the job of allowing somebody non-skilled to build something functional it can be a very good thing (even if programming logic escapes them)
但是,鉴于最近的工作经验;给非技术人员提供这样一个图形界面用于创建基本的拖放程序,让我*地继续进行一些“正确的”编程会很有用;-)如果它可以完成的工作允许某些非技术人员构建功能性的东西,这可能是一件非常好的事情(即使编程逻辑逃脱它们)
There comes a point in such a system where it becomes easier to define what you want to do using literal C++ code, rather than have a user interface getting in the way; it can get frustrating to the sessioned programmer knowing the precise code that needs to be written but then only being limited to the design GUI. I'm specifically thinking about a more common application, such as html editors/designers in which they allow newbies to build their websites without knowing any html at all.
在这样的系统中有一点,使用文字C ++代码更容易定义您想要做的事情,而不是让用户界面妨碍;对于会话程序员来说,知道需要编写的精确代码然后仅限于设计GUI会让他感到沮丧。我特别想到一个更常见的应用程序,例如html编辑器/设计器,它们允许新手在不知道任何html的情况下构建他们的网站。
It would be interesting to see how such a system would handle the dynamic allocation of memory, and the different states of a program as time progressed; I suspect that there are some very basic programming concepts that may be difficult to represent graphically.. Polymorphism..? Virtual Classes, LinkList, Stacks/Circular Queues. I wonder for a moment how you would explain an image compression algorithm (such as jpg) successfully too without the help of a gigantic display screen.
看看这样一个系统如何处理内存的动态分配,以及随着时间的推移程序的不同状态,将会很有趣;我怀疑有一些非常基本的编程概念可能难以用图形表示..多态性..?虚拟类,链接列表,堆栈/循环队列。我想知道如何在没有巨大显示屏的帮助下成功解释图像压缩算法(如jpg)。
I also wonder if such a system would even go to such a low level, and whether you would be dealing with abstracted concepts and the compiler would be working out the best way to do something.
我也想知道这样的系统是否会达到如此低的水平,以及你是否会处理抽象的概念,编译器会找出最好的方法来做某事。
#9
1
I've been working on a new model-driven software development paradigm named ABSE (http://www.abse.info) that supports end-user programming: It's a template-based system that can be complemented with transformation code. I also have an IDE (named AtomWeaver) implementing ABSE that is in pre-alpha stage right now.
我一直在研究一种名为ABSE(http://www.abse.info)的新模型驱动软件开发范例,它支持最终用户编程:它是一个基于模板的系统,可以用转换代码进行补充。我还有一个IDE(名为AtomWeaver),它实现了现在处于pre-alpha阶段的ABSE。
With AtomWeaver, as an expert/architect, you build your knowledge Templates, and then the developers (or end-users if you make your meta-models simpler) can just "assemble" systems by building blocks, and then filling template parameters in form-style editors.
使用AtomWeaver,作为专家/架构师,您可以构建知识模板,然后开发人员(或最终用户,如果您使元模型更简单)可以通过构建块“组装”系统,然后填写表单中的模板参数风格的编辑。
At the end, pressing the "Generate" button will create the final system as specified by the architect/expert.
最后,按“生成”按钮将创建建筑师/专家指定的最终系统。
#10
0
I'm surprised you think function pointers would be a particular problem. How about anything at all to do with pointers?
我很惊讶你认为函数指针会成为一个特殊的问题。如何处理指针呢?
A programming language can be represented by a hierarchy of nodes - that's exactly what the compiler turns it into. It is very strange that the UI for editing programs is still a sequence of characters that get parsed, because the degrees of freedom in the editor is way larger than the available set of allowed choices. But intellisense helps to reduce this problem a lot.
编程语言可以由节点层次结构表示 - 这正是编译器将其转换为的结构。用于编辑程序的UI仍然是一系列被解析的字符,这是非常奇怪的,因为编辑器中的*度大于可用的允许选择集。但intellisense有助于减少这个问题。
C++ would be a strange choice to base such a system on.
基于这样的系统,C ++将是一个奇怪的选择。
#11
0
I think the major problem of this kind of IDEs are that the code generated becomes unmantainable easily.
我认为这种IDE的主要问题是生成的代码很容易变得难以理解。
This happened to Delphi. It's a really nice tool to develop some kind of applications, however, when we start adding complex relationships between the components, start adding Design Patterns, etc. the code grows to an unmantainable size.
这发生在德尔福。这是开发某种应用程序的一个非常好的工具,但是,当我们开始在组件之间添加复杂关系,开始添加设计模式等时,代码会增长到不可比较的大小。
I believe it's also because graphical tools don't apply the concept of MVC (or if they do, it's only in the way that the IDE understands).
我相信这也是因为图形工具不应用MVC的概念(或者如果它们这样做,它只是以IDE理解的方式)。
It can be really helpful for prototypes and very small applications that don't tend to grow, otherwise it can become a mess for the developer(s)
对于原型和非常小的不易增长的应用程序来说它真的很有用,否则它会成为开发人员的一团糟。