26

Re: The report on Nitra

VD> Sounded XAML and QML from that also are ugly that their authors instead of creation of readable syntax decided to use XML, and in absence something comparable with Nitra washed down  typification of these . And at all thus programmers prefer to describe UI on XAML and QML, instead of  the similar code on C# and a C ++. Give an example how it can be made "beautifully": , force HTML and XAML just in pretentiousness and  to add  it is possible and c# - a code, but just because of bad  and  such approach, it is used only in the most extreme cases

27

Re: The report on Nitra

Hello, meadow_meal, you wrote: _> From what? From implementation Go/Rust on Nitra? For whom and what for it could be necessary? Under some conditions why also is not present? To develop language on Nitra where easier than manually. It is possible to make easily support of all necessary IDE. Plus to make languages expanded. But for this purpose, it is necessary that Nitra has been transferred on other platforms itself and would allow to do of a box  languages. In the presence of financing it can be made quickly enough.

28

Re: The report on Nitra

Hello, novitk, you wrote: N> Here analog WPF on built in DSL for . Syntax selection, autocompletion, debugging and other works from a box in normal IDEA. N> N> object TextTestApp extends UiExampleApp {N> val tte = TextTestEntity () N> def mainGui = gui {N> Window (_.title: = "Text Properties Test", _.renderAsPage: = true) {N> Grid (_.columns: = 2) {N> Text (N> _.enabled <- tte.enabled, N> _.readOnly <- tte.readOnly, N> _.span: = (2, 1), N> _.numOfVisibleLines <- tte.numLines, N> _.tag: = "testText", N> _.tooltip: = tte.tooltip, N> _.hotKeys: = Seq (HotKey (_.key: = Key. F1)-> tte.sayGoodbye _) N>) <- tte.text N> Label (_.span: = (2, 1), _.tag: = "testTextStatus") <- tte.text1 N> Button (_.text <- tte.text2, _.tag: = "toggleText")-> tte.toggleEnabled N> Button (_.text <- tte.text3, _.tag: = "readWriteText")-> tte.toggleReadOnly N> Button (_.text: = "More Lines", _.tag: = "moreLinesBtn")-> tte.moreLines N> And here analog implemented on Nitra (is called Ammy language): alias FormField (labelText, binding) {StackPanel {Orientation: Horizontal TextBlock {Text: $labelText} TextBlock {Text: $binding}}} Window "MyApp. MainWindow" {Title: "My First App" StackPanel {@FormField ("First name", bind FirstName) @FormField ("Last name", bind LastName) TextBlock {Text: bind convert (MyViewModel vm) => "Hello," + vm. FirstName + "" + vm. LastName}}}

29

Re: The report on Nitra

Hello, meadow_meal, you wrote: _> At first Kolesiki for some reason resulted XAML as an example of lacks of Nitra, and now XAML the pattern is answerable for all exterior DSL. What for the logician such - exterior DSL are not necessary, because XAML it is not necessary? It not logic, and its absence. Simply it would be desirable to criticize and begin pulling for ears of "arguments". By the way XAML at all its wretchedness and  very much even it is claimed. Itself here now on Xamarin. Forms application I write. Truth  I am not engaged. There and without it logicians suffice.

30

Re: The report on Nitra

Hello, VladD2, you wrote: VD> Tell you you do not see logical errors these lines? Well, how it is possible to prove any examples "" something? And generators of parcers, CSS, Markdown, HTML, LaTeX, Liquid? They as in your "theory" it is inscribed? Vlad, at me dab here is wider. I quite agree that Nitra approaches for handling exterior DSL, including set forth above. Simply I do an emphasis that internal it is much more convenient. VD> and the main thing! How worthless integration DSL th can justify application  which is just created for good integration? Exterior DSL - worthless integration. In Nitra good integration only with N1. VD> Sounded XAML and QML from that also are ugly that their authors instead of creation of readable syntax decided to use XML, and in absence something comparable with Nitra washed down  typification of these . In QML not XML, and a certain json-similarity with js, but you are absolutely right, typification there misses, as DSL completely exterior and as language was dynamics is taken certainly. But there convenient , instead of poverty from . VD> And at all thus programmers prefer to describe UI on XAML and QML, instead of  the similar code on C# and a C ++. Because these languages are not suitable for creation DSL. But how helps here Nitra? You will not implement  parser/tipizator for seamless integration. N>> the correct way - LINQ, that is seamless integration into target language. VD> aha. Only one way! Not only, but preferable. IRL all certainly is more difficult. VD> and on surprising coincidence, Nitra just also it is intended for creation of such languages. And it gives both means of seamless integration exterior, and internal DSL. Internal DSL there for N1 that not so . For exterior languages Nitra as I already told, approaches, but I do not know any seamless (with  etc.) Integrations exterior DSL with target language. VD> the generator if it is based on such high-level abstractions (by the way, DSL) as Java byte code, LLVM or.Net MSIL is insignificant enough code amount in the compiler. The compiler master code is made by check of types and resolution of names. I do not have confidence that check of types which you implemented in Nitra strongly helps at implementation of the modern languages with the heaped up type systems, for example such as the Rock or Rast. The parcer on indents as I understand, too is not present. On all time etc. is necessary, but I simply judge about leaking a state and perspectives. VD> on what to create  easier? In general purpose language, writing all stages of compilation manually, or on means which does not give only the last stage? In general I do not know, fairly. If language + a platform.+ knowledge of Nemerle => on Nitra probably faster. VD> to Tell "" and it "is not necessary" always is easier, than even simply to investigate in . I investigated into a problematics and anywhere  you did not name. Simply area application and the approach to me does not see perspective.

31

Re: The report on Nitra

Hello, VladD2, you wrote: VD> Window "MyApp. MainWindow" {VD> Title: "My First App" VD> StackPanel {VD> @FormField ("First name", bind FirstName) VD> @FormField ("Last name", bind LastName) VD> TextBlock {VD> Text: bind VD> convert (MyViewModel vm) => "Hello," + vm. FirstName + "" + vm. LastName VD>} VD>} VD>} VD> [/q] Equivalent QML, dynamics... Type ViewModel is not conducted. I can write FirsName IDE to me does not help.

32

Re: The report on Nitra

Hello, novitk, you wrote: N> Equivalent QML, dynamics... Type ViewModel is not conducted. Tell, what for you speak about about what you know nothing? Meanwhile you missed the mark at all points.  from you useless. N> I can write FirsName IDE to me does not help. Generally helps. But you can continue to invent further. Your task not to understand and to invent excuses.

33

Re: The report on Nitra

Hello, VladD2, you wrote: N>> Equivalent QML, dynamics... Type ViewModel is not conducted. VD> tell, what for you speak about about what you know nothing? Meanwhile you missed the mark at all points.  from you useless. Therefore it is necessary to give the full code, instead of a piece. N>> I can write FirsName IDE to me does not help. VD> Generally helps. But you can continue to invent further. Your task not to understand and to invent excuses. Give the full code with viewModel and whores. We compare.

34

Re: The report on Nitra

Hello, takTak, you wrote: VD>> Sounded XAML and QML from that also are ugly that their authors instead of creation of readable syntax decided to use XML, and in absence something comparable with Nitra washed down  typification of these . And at all thus programmers prefer to describe UI on XAML and QML, instead of  the similar code on C# and a C ++. T> give an example how it can be made "beautifully": I was already tired to result. Here https://github.com/AmmyUI/AmmyUI alias FormField (labelText, binding) {StackPanel {Orientation: Horizontal TextBlock {Text: $labelText} TextBlock {Text: $binding}}} Window "MyApp. MainWindow" {Title:" My First App "StackPanel {@FormField (" First name ", bind FirstName) @FormField (" Last name ", bind LastName) TextBlock {Text: bind convert (MyViewModel vm) =>" Hello, "+ vm. FirstName +" "+ vm. LastName}}} T> , force HTML and XAML just in pretentiousness and  to add  it is possible and c# - a code, but just because of bad  and  such approach, it is used only in the most extreme cases XML a completely not not readable format. To its computer to read conveniently, but for the person it is a dial-up . Plus is too much dynamics. For business it is not necessary, and bugs the sea.

35

Re: The report on Nitra

Hello, novitk, you wrote: N> Therefore it is necessary to give the full code, instead of a piece. The site is inaccessible thanking . When , come on http://www.ammyui.com/ Meanwhile something is on  https://github.com/AmmyUI/AmmyUI N> Give the full code with viewModel and whores. We compare. You can simply download Ammi and try itself. Unfortunately now the site is inaccessible. It is possible to ask to give the author an alternative link on a product.

36

Re: The report on Nitra

Hello, VladD2, you wrote: N>> Give the full code with viewModel and whores. We compare. VD> you can simply download Ammi and try itself. Unfortunately now the site is inaccessible. It is possible to ask to give the author an alternative link on a product. What for any site? Here there should be 10 lines. Here to you the full code. Repeat on Ammi: @entity class MyViewModel () {@node (tweak = true) val firstName = "" @node (tweak = true) val lastName = "" @node def hello = "Hello," + firstName + "" + lastName} object MyExampleApp extends xxxxUiApp {val vm = MyViewModel.uniqueInstance () def formField (nodeKey: NodeKey [String]) = gui {Group () {Label (_.text: = nodeKey.propertyInfo.name) Text (_.text.bind (nodeKey, BindKind. TwoWay))}} def mainGui = gui {Window (_.title: = "My First App") {Grid (_.columns: = 1) {formField (nodeKeyOf (vm.firstName)) formField (nodeKeyOf (vm.lastName)) Label () <- vm.hello}}} runUi (HtmlRenderEngine. Angular)}

37

Re: The report on Nitra

Hello, novitk, you wrote: N> What for any site? Here there should be 10 lines. Here to you the full code. Repeat on Ammi: To me as to the author, it seems that the code on Emmi more readable http://rsdn.org/forum/philosophy/7138070.1 the Author: VladD2 Date: 08.05 00:31 But also you are right is, typification  at present is not present. It not absolutely trivial task in view of the architecture  in XAML. But, for example,  after key c convert it is typified completely. Now the mode generally went to mold UI in general purpose language. I even for the LiveXAML  similar functionality: https://twitter.com/ionapps/status/993399338255732736 But it shows wretchedness XAML as language and unwillingness of the big companies to spend resources on modern language development more likely. I all the same would prefer something like Ammy only licked and completely typified. The same example on the Rock though is close by an amount of lines, but adds many unnecessary characters, from which  in eyes.

38

Re: The report on Nitra

VD>>> Sounded XAML and QML from that also are ugly that their authors instead of creation of readable syntax decided to use XML, and in absence something comparable with Nitra washed down  typification of these . And at all thus programmers prefer to describe UI on XAML and QML, instead of  the similar code on C# and a C ++. T>> give an example how it can be made "beautifully": VD> I was already tired to result. Here https://github.com/AmmyUI/AmmyUI VD> VD> alias FormField (labelText, binding) VD> {VD> StackPanel {VD> Orientation: Horizontal VD> TextBlock {Text: $labelText} VD> TextBlock {VD> Text: $binding VD>} VD>} VD>} VD> Window "MyApp. MainWindow" {VD> Title:" My First App "VD> StackPanel {VD> @FormField (" First name ", bind FirstName) VD> @FormField (" Last name ", bind LastName) VD> TextBlock {VD> Text: bind VD> convert (MyViewModel vm) =>" Hello, "+ vm. FirstName +" "+ vm. LastName VD>} VD>} VD>} VD> T>> , force HTML and XAML just in pretentiousness and  to add  it is possible and c# - a code, but just because of bad  and  such approach, it is used only in the most extreme cases VD> XML a completely not not readable format. To its computer to read conveniently, but for the person it is a dial-up . VD> Plus is too much dynamics. For business it is not necessary, and bugs the sea. , it Razor, only the side view in XAML is such pieces as behaviors, eventTriggers, integration with win32 and winforms, it in the resulted case is not present anything, but at all in it an essence as soon as it will be a question of any more difficult case, type hierarchical , this AmmyUI ceases to work as  and the heap of a rake is required, that all construction did not fall not to mention what even speeches are not present using it with any ,  application structures, navigation and any styles of the same devExpress as a result on an output it turns out next ", ",  on, a maximum, 10 windows

39

Re: The report on Nitra

Hello, takTak, you wrote: T> , it Razor, only side view T> in XAML is such pieces as behaviors, eventTriggers, integration with win32 and winforms, it in the resulted case is not present anything, but at all in it an essence as soon as it will be a question of any more difficult case, type hierarchical , this AmmyUI ceases to work as  and the heap of a rake is required, that all construction did not fall T> not to mention what even speeches are not present using it with any ,  application structures, navigation and any styles of the same devExpress T> as a result on an output it turns out next ", ",  on, a maximum, 10 windows of Eeeej, are not necessary here Any , behaviors, triggers and other pieces are supported in Ammy as it is compiled in XAML. And to use all it it is more convenient, thanking  and . On http://www.ammyui.com/ there are examples, but in Russia, diligence , a site now .

40

Re: The report on Nitra

On  a sensible estimation ammy : QML/js crap is the worst thing that happened to Qt... Sad that it is an inspiration for other projects. Literally back to Basics... In particular Microsoft Visual Basic (v.6.0).FRM files: Evolution is just a spiral indeed. VERSION 5.00 Begin VB.Form DemoForm BackColor = &H00000000& Caption = "Screen Blanker Demo" ClientHeight = 960 ClientLeft = 1965 ClientTop = 1965 ClientWidth = 7470 ForeColor = &H00000000& Begin Property Font name = "MS Sans Serif" charset = 0... End Property

41

Re: The report on Nitra

I> Eeeej, is not necessary here Any , behaviors, triggers and other pieces are supported in Ammy as it is compiled in XAML. And to use all it it is more convenient, thanking  and . On http://www.ammyui.com/ there are examples, but in Russia, diligence , a site now . , I am not familiar with  "personally" and I apologize well, I can fasten to  any Prism or caliburn, and in full ? I can use o styles devExpress / telerik?

42

Re: The report on Nitra

Hello, takTak, you wrote: T> , I am not familiar with  "personally" and I apologize T> well, I can fasten to  any Prism or caliburn, and in full ? T> I can use o styles devExpress / telerik? Certainly. All that worked for you in XAML will work in Ammy.

43

Re: The report on Nitra

Hello, takTak, you wrote: T> on  a sensible estimation ammy : T> T> QML/js crap is the worst thing that happened to Qt... Sad that it is an inspiration for other projects. I do not know what problems at QML in Qt so be responsible for it I can not. But I know XAML development under all main platforms, and I know it becomes how much easier life with Ammy.

44

Re: The report on Nitra

Hello, ionoy, you wrote: I> Hello, takTak, you wrote: T>> , I am not familiar with  "personally" and I apologize T>> well, I can fasten to  any Prism or caliburn, and in full ? T>> I can use o styles devExpress / telerik? I> it is finite. All that worked for you in XAML will work in Ammy. I.e. that you offer: it to write the code under  5, then to use , to compile in  10, and in what a profit? I.e. if usually the bug  and is started by what changes XAML application to look, in your case one more additional step in the form of transcompilation, in what a profit is added? Especially not the fact that that XAML that turns out on an output will coincide completely that is necessary for successful operation with Prism/devExpress and Co.

45

Re: The report on Nitra

Hello, takTak, you wrote: T> i.e. that you offer: it to write the code under  5, then to use , to compile in  10, and in what a profit? T> especially not the fact that that XAML that turns out on an output will coincide completely that is necessary for successful operation with Prism/devExpress and Co. What does the fact mean not? Once again I speak, on Ammy it is possible to repeat all that is in XAML. Will be or will not work, depends only on the programmer. And a profit in: 1. . I think, all faced with XAML the code from which  in eyes because of an abundance of characters, opening tags / closing, and complexity implementation DRY. 2. Extensibility. A real example: <ffimageloading:CachedImage.GestureRecognizers> <TapGestureRecognizer Command = "{Binding TapCommand}" CommandParameter = "SomeText"/> </ffimageloading:CachedImage.GestureRecognizers> In one project which to me should be supported, the similar code was applied in approximately 20 places. By means of XAML you cannot abstract from it in any way. Here that it is possible to make with Ammy. mixin TapGestureRecognizer (command, text) for CachedImage {GestureRecognizers: TapGestureRecognizer {Command: bind $command CommandParameter: $text}} then in different places CachedImage {... #TapGestureRecognizer ("Tap1Command", "SomeText 1")...} CachedImage {... #TapGestureRecognizer ("Tap2Command", "SomeText 2")...} 3.  converters. In XAML on everyone  it is necessary or to write the converter, or to add property in VM. Ammy allows to write inline converters (with check to compile time). 4. Almost full typification, except some counters . Though  for XAML this advantage practically levels modern.

46

Re: The report on Nitra

Hello, takTak, you wrote: Here by the way video showing real development on Ammy https://vimeo.com/198873582

47

Re: The report on Nitra

I> That the fact means not? Once again I speak, on Ammy it is possible to repeat all that is in XAML. Will be or will not work, depends only on the programmer. Aha, here you also got! This that phrase for which to you any normal manager tears off at once a head start with programmers who know nothing if the programmer except most XAML still has to know knowledge any there ammy conventions it not in what someone will be voluntary engaged

48

Re: The report on Nitra

I> Here by the way video showing real development on Ammy https://vimeo.com/198873582 thanks, I at a leisure, can, I will look at council: make an example as this you Ammy is combined with Prism / Navigation API / devExpress Themes, lay out all it on github then it can be will to represent  interest for real enterprise developers

49

Re: The report on Nitra

Hello, takTak, you wrote: I>> That the fact means not? Once again I speak, on Ammy it is possible to repeat all that is in XAML. Will be or will not work, depends only on the programmer. T> aha, here you also got! T> this that phrase for which to you any normal manager tears off at once a head Oh these blood-thirsty managers. T> start with programmers who know nothing if the programmer except most XAML still has to know knowledge any there ammy conventions it not in what someone will be voluntary engaged Yes is not present there any knowledge. Ammy is practically the same JSON. If you do not want  with additional syntax bluntly you copy attributes from XAML'. Type ` Text = {Binding A} => Text: "{Binding A}"`

50

Re: The report on Nitra

Hello, takTak, you wrote: I>> Here by the way video showing real development on Ammy https://vimeo.com/198873582 T> thanks, I at a leisure, can, I will look T> at council: make an example as this you Ammy is combined with Prism / Navigation API / devExpress Themes, lay out all it on github then it can be will to represent  interest for real enterprise developers If fairly, I do not try to attract developers at present. It would not be desirable operation and so , and to put the time in support of Ammy to me. Ammy now is an example of how the correct language for marking UI (in my judgement certainly could look). In practice support.NETStandard as it appeared later than Ammy does not work. For this purpose it is necessary to rewrite , and I do not want to do it. There are defects in studio integration, are not present  VS for Mac. More shortly, infrastructural problems suffice, and to solve them, actually, there is nobody.