Jump to content

Separate category for NXG?


Recommended Posts

As topics about LabVIEW NXG are going to start growing more and more numerous, it would be nice to have a proper folder to put them. Could an admin create a dedicated folder or category where it would make the most sense (at their discretion)? 

  • Like 1
Link to comment

Personally I think this is a good idea, and NI already is doing something similar by tagging NXG posts so they can be identified.  I do think there are some issues with making a new subforum.  One is if we do make an NXG subforum, then what happens when it isn't called NXG anymore?  I've heard that some day NI will just call it "LabVIEW" and the LabVIEW we all know and love might be called something else, like "Classic LabVIEW".  But then again that might not be for many years until NXG has functional parity with LabVIEW.  There are also going to be times when a subject is about NXG and Object Oriented Programming, which subforum should it go into?  Now we'd say NXG, but in a few years would it make more sense to put it in OO?  Anyway I'll talk to some admins and see if we can agree on something.

  • Like 1
Link to comment

Given that G is the same language in both -- the compiler and execution system are [mostly] the same -- I suggest creating a "LabVIEW NXG Development Environment" section. That way it is clear that architecture questions go in the version agnostic section (since the right way to write code shouldn't depend upon the environment), but UX changes go to the version specific. There will be some muddiness as NXG develops (right now, no classes; in the future, gaining components, something the current dev environment isn't planning to develop), but for the most part, I think this would serve best.

For the record, I've got a similar conversation happening inside NI about the Idea Exchange. ;-)

Link to comment
54 minutes ago, Aristos Queue said:

Given that G is the same language in both -- the compiler and execution system are [mostly] the same -- I suggest creating a "LabVIEW NXG Development Environment" section. That way it is clear that architecture questions go in the version agnostic section (since the right way to write code shouldn't depend upon the environment), but UX changes go to the version specific.

Except that all the primitives have changed so it is not just a UX "option". It is, to all intents and purposes, a different language and examples, snippets and demos aren't synonymous even if they were in an "architectural" sense.

Link to comment
8 minutes ago, ShaunR said:

Except that all the primitives have changed so it is not just a UX "option". It is, to all intents and purposes, a different language and examples, snippets and demos aren't synonymous even if they were in an "architectural" sense.

Exactly how far apart the two dialects are and whether they constitute different languages is a judgement call that shouldn't affect the forums. If the person's question does hinge on something that is platform specific, then I would direct them to the specific forum. If it is a more general question, I would not. What I do not think should happen is somehow that all the years of good commentary on software design that LAVA has built up should suddenly be relegated to an "old news" bin just because the UX got a rewrite. So the main headings of

I would not fork. The platform-specific ones of

I would suggest forking.

Similarly, I would not fork "OpenG" -- the API should be the same in both dialects. Apply same rubric for any other subforums.

Edited by Aristos Queue
Link to comment
1 hour ago, Aristos Queue said:

What I do not think should happen is somehow that all the years of good commentary on software design that LAVA has built up should suddenly be relegated to an "old news" bin just because the UX got a rewrite

That's my point. The UI didn't just get a rewrite. LabVIEW, as it is now, is slowly being grandfathered in favour of LabVIEW.NET. All the community contributed code will eventually be obsolete and the forums are example led not white-paper led!

Link to comment
5 hours ago, ShaunR said:

That's my point. The UI didn't just get a rewrite. LabVIEW, as it is now, is slowly being grandfathered in favour of LabVIEW.NET. All the community contributed code will eventually be obsolete and the forums are example led not white-paper led!

I don't know about that. To pick some examples from the main labview forum:

https://lavag.org/topic/20126-aligning-two-waveforms/
I can't imagine that this would become obsolete. Sure some of the nodes might change (at NI week they showed off how they are distinguishing between two use cases polymorphs currently cover, so maybe we see "feature detection{2d dbl, peak}" rather than just "peak detection.vi"), but i think the valuable part is the discussion here.

https://lavag.org/topic/20151-how-to-draw-circles-and-lines-in-intensity-graph/
Yes this will obviously become obsolete. But, its also in the wrong forum anyway, arguably, as its a user interface question. Lava doesn't have anywhere near enough volume to matter.

https://lavag.org/topic/20169-storingimporting-daqmx-task-configurations/
Will probably become obsolete as well, but ideally in favor of an obvious built-in solution to the problem, rather than a hack

So I mean sure there will be some obsolete stuff during the transition but I highly doubt that will cause many problems

5 hours ago, ShaunR said:

LabVIEW, as it is now, is slowly being grandfathered in favour of LabVIEW.NET.

With your past comments on .net I'm assuming you meant this to be insulting, but I honestly think this is a better name. For one thing it rolls off the tongue better than labview nxg, and more importantly it makes it sound like labview is trying to align itself to be more like 'a real programming language' which is nice.;)

Edited by smithd
Link to comment
6 hours ago, smithd said:

I don't know about that. To pick some examples from the main labview forum:

https://lavag.org/topic/20126-aligning-two-waveforms/
I can't imagine that this would become obsolete. Sure some of the nodes might change (at NI week they showed off how they are distinguishing between two use cases polymorphs currently cover, so maybe we see "feature detection{2d dbl, peak}" rather than just "peak detection.vi"), but i think the valuable part is the discussion here.

So I mean sure there will be some obsolete stuff during the transition but I highly doubt that will cause many problems

Snippets are code. There are many examples in that thread and the litmus is to take them out and see how much sense the thread makes, You can't rely on them purely as images anymore because all the icons have changed! (e.g " Here I've used it just to shift each waveform"). I've always hated snippets but if LabVIEW.NET ( ;) ) can accept all the old ones like LabVIEW does now and .NET ones can be dropped into LabVIEW,proper, as is. Then it may mean there is no reason to have different topics at all.

Edited by ShaunR
Link to comment
On 6/12/2017 at 4:54 PM, ShaunR said:

LabVIEW, as it is now, is slowly being grandfathered in favour of LabVIEW.NET.

This is false. Where did you get this impression?

On 6/13/2017 at 3:00 AM, ShaunR said:

 I've always hated snippets but if LabVIEW.NET ( ;) ) can accept all the old ones like LabVIEW does now and .NET ones can be dropped into LabVIEW,proper, as is. Then it may mean there is no reason to have different topics at all.

I don't think I've heard anyone propose this. The forward direction from current platform to next platform is certainly a possibility. I'll propose it to the team.

Link to comment
On 6/12/2017 at 4:54 PM, ShaunR said:

LabVIEW, as it is now, is slowly being grandfathered in favour of LabVIEW.NET.

Wait... I think I understand what you mean... I took "LabVIEW.NET" to mean a .NET execution engine and requiring .NET programming.

You just mean that eventually everyone will be using LabVIEW NXG, right? Ok. That's true. It's years away, but, yes, that is the migration path. But the current platform VIs can be migrated by users. And your suggestion about allowing snippets to drop directly is a good one.

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.