Zaluum (attempt at LabVIEW Clone?)

[smarlow]

I was Googling around on the subject of graphical programming and open source and came across this.  I have never seen it before.  It looks pretty rough and new, but also very familiar.  Seems to be Java-based.  I have not yet downloaded it.  Has anyone else seen this?  Opinions please.

 

http://www.zaluum.com/index.html

[ShaunR]

I was Googling around on the subject of graphical programming and open source and came across this.  I have never seen it before.  It looks pretty rough and new, but also very familiar.  Seems to be Java-based.  I have not yet downloaded it.  Has anyone else seen this?  Opinions please.

 

http://www.zaluum.com/index.html

 

Well. Ignoring my extreme dislike for Java. It should have one huge advantage over LabVIEW in that you should be able create custom controls and, perhaps more importantly, dynamically create them on a FP. If they wrote it in something else I'd be really sold on it and have downloaded it already

 

Nice little find there. I will be keeping my eye closely on it.

[chris754]

I really like this idea. Don't think its ready for prime time yet, but really like the idea of mixing java (I actually like java ) with graphical programming. I can see myself writing classes with java and doing my threading with graphics. I do wonder if they are breaking some NI patents/IP however, some things look rather similar. Seems cool nevertheless for my quick glance through it this morning.

[hooovahh]

I've seen several attempts at making a text based language have a graphical interface.  Something like "drop blocks down" and "generate text code" which just feels bolted on in my opinion.  I haven't look at this product itself so my comment might not be applicable.

 

One thing I feel NI has that is an advantage is many years of doing graphical programming.  That's not to say they aren't sometimes stuck in their ways, but I feel like they have tried a bunch of things, and have a decent idea of what things historically worked, and didn't work.  And as a result I'd hope that the tools NI develops are more mature because of their history in the graphical programming world.

 

Only time will tell if some up and coming language does some stuff right that NI did wrong in hindsight.

[chris754]

Graphical programming is probably due for some transformation. Text-based languages transform monthly. Graphical has been relatively stuck for a while. An upstart would be welcome to push NI and graphical programming in general.

[hooovahh]

Graphical programming is probably due for some transformation. Text-based languages transform monthly. Graphical has been relatively stuck for a while. An upstart would be welcome to push NI and graphical programming in general.

Yeah you have a good point.  In other industries you see some random small company out of nowhere come up with some new way of doing things that ultimately is good for competition. 

[smarlow]

Thanks for your replies.  When I first came across the website last week, it looked brand new because there were no comments.  However, after looking at some of the other pages at the site, I found one page with a comment that is more than three years old.  It seems to be the only comment.  One comment from three years ago?  That does not portend a successful effort.  I agree with others here that it is disappointing it is built as a framework on top of Java, which I also despise.  It would make it cross-platform, but also extremely clumsy, IMHO.  

 

I always had the thought that an decent open-source effort would be built on ANSI C or C++.  The source code could be SVG (XML), with a namespace and special tags for the embedded C code, and standard SVG for the graphical elements.  Such a language would be extensible at the base function level by following a simple specification for the programming elements.  The compiler would be a standard C compiler modified to parse the SVG and extract the embedded code contained in the tags for compilation.  The execution environment would be tricky, and definitely the hardest part. But it could be done.

 

Some comments were made about NI's patents/IP.  The first couple of patents that describe all the basic elements of LabVIEW (Graphical arithmetic functions, data manipulation, loops, structures, etc.) have all long since expired.  I've been waiting for someone to take on the task of creating a clone.  I am glad someone finally took a stab at it, even if it appears to be a non-starter based on Java.  I will continue to keep my eye out for a really serious effort.

[FixedWire]

Let's keep in mind that not changing too much is sometimes a good thing. The aerospace industry for example, with all the requirements needs to stay stuck in time for 20 years. I'm currently using LV2011 because of this.

 

NI's HW integration is quite solid and good HW creates good systems.

 

However, NI, your 20 GB updates are just bad news...just say'n.

[hooovahh]

However, NI, your 20 GB updates are just bad news...just say'n.

Are you talking about the NI Service Updater thing?  Yeah I have never used that to update any PC, and never will.  I have a hard time trying to convince it to stop bothering me.  I don't upgrade software, drivers, operating systems or anything in the PC ecosystem unless there is a good reason.  It just adds new risk changing the environment from what you've been using.  So unless you are in an academic environment, or just playing around and not making production level applications, why would I ever want you updating a thing?

[ShaunR]

Are you talking about the NI Service Updater thing?  Yeah I have never used that to update any PC, and never will.  I have a hard time trying to convince it to stop bothering me.  I don't upgrade software, drivers, operating systems or anything in the PC ecosystem unless there is a good reason.  It just adds new risk changing the environment from what you've been using.  So unless you are in an academic environment, or just playing around and not making production level applications, why would I ever want you updating a thing?

 

Wise words hardly ever heeded.

[Aristos Queue]

Are you talking about the NI Service Updater thing? ... why would I ever want you updating a thing?

I can't say why, but I know there were lots of requests for us to build this, so some users definitely use it.

Regarding a competitor for NI... I would welcome it. The problem is the sheer expense. I've contemplated building different graphical languages just as prototypes for people to play with. I can leverage all sorts of rendering tools, formats, etc, but an edit environment is expensive compared to a text editor. Every graphical language needs a largely unique environment. I'm lucky ... I can hack the existing LabVIEW environment to simulate syntax, but doing this from scratch would be way more than I could undertake alone, at least with the tools I've seen. I think it would take corporate level investment to do one with graphics at the quality users expect today. I doubt LabVIEW could even get off the ground if attempted for the first time today.

[hooovahh]

I can't say why, but I know there were lots of requests for us to build this, so some users definitely use it.

Thanks for this, I always assumed it was NI just putting resources into making something that users didn't want.  Now I actually know it is the users fault for asking for something that they shouldn't need.

[Aristos Queue]

I figure most people like being able to apply patches easily. Everyone auto upgrades most apps and even the OS these days. Why would patches for LabVIEW be any different?

[Neil Pate]

I figure most people like being able to apply patches easily. Everyone auto upgrades most apps and even the OS these days. Why would patches for LabVIEW be any different?

 

 

Apps are mostly sandboxed. Upgrading DAQmx, for example, affects every version of LabVIEW installed on my PC. As a developer actively supporting software in multiple versions of LabVIEW on the same PC (because putting each one in a VM is still a pipe dream) this is a problem.

 

Edit: OK you did say only patches for LabVIEW, but even that is tricky. If you have validated a system using a particular version of LabVIEW all further incremental changes really ought to be done using the identical software configuration. Even something like going from LabVIEW2014f1 to LabVIEW2014f2 would probably require significant revalidation of certain software, or a lot of blind faith.

Edited March 6, 2015 by Neil Pate

[ShaunR]

Everyone auto upgrades most apps and even the OS these days. Why would patches for LabVIEW be any different?

You mean everyone "at home" auto upgrades where a bug isn't going to slice someones arm off and software is 10s of dollars not thousands with penalty clauses.

Edited March 6, 2015 by ShaunR

[hooovahh]

Everyone auto upgrades most apps and even the OS these days.

Please don't generalize.  The testers I use, are I think the feeling around here, is test systems can fall apart for any number of seemingly insignificant reasons.  And if my tester blue screens after a Windows update, I'm going to blame the update.  And if my program was working fine on F1 patch and then it auto updates to an F2 patch and all of the sudden things stop working, my boss and customer aren't going to give a hoot what cause the problem they just want it to not happen again.  Having as much control over that environment as possible helps me ensure I can do my job.  I see automatic Windows updates, automatic driver updates, automatic patches, anti-virus, and firewall programs and ways of me loosing control over my environment.

[Aristos Queue]

Please don't generalize. 

I'm not generalizing. I stated what is, to the best of my knowledge, a fact: Everyone upgrades most apps. That is the default setting in home environments, as you ShaunR noted, but most corporate IT departments that I know of have similar policies on the corporate machines. Windows, Oracle and other key parts of my software stack get patched every week (Friday nights) automatically by my IT department. Around here, if Visual Studio pushes out a patch, every developer hits upgrade as soon as they can afford a reboot. If it is a brand new version, we don't auto-upgrade, but we definitely accept all patches (though we try to push LV onto the latest version of Visual Studio within a year).

 

I see automatic Windows updates, automatic driver updates, automatic patches, anti-virus, and firewall programs and ways of me loosing control over my environment.

Yes. That is the world of modern software development. By and large, so far as I can tell, those patches do a lot more good than harm. NI would be remiss if it did not participate in that ability to update on an ongoing basis. You don't have to accept the upgrade, but customers expect NI to make it available as an option.

Edited March 6, 2015 by Aristos Queue

[ShaunR]

most corporate IT departments that I know of have similar policies on the corporate machines. Windows, Oracle and other key parts of my software stack get patched every week (Friday nights) automatically by my IT department.

This axiom is usually completely false. IT departments have stringent policies on patches and things like VC++ et al usually require sign off by a competent authority. I expect if you dig deeper there is a whole process before pushing out patches/updates. It is for such policies that Windows XP is still in use in the finance sector and Microsoft are not forcing updates on enterprise users in Windows 10 as they are with the chattel consumers.

 

I know most software suppliers feel they own our hardware (less so NI, but they are getting there) and at liberty to install anything that they deem appropriate for their or their country's business but people like me and Hooovahh are here to dispel that myth.....just sayin'

Edited March 6, 2015 by ShaunR

[Aristos Queue]

Again, I fail to see the problem with offering you the upgrade. We do not auto install the upgrade.

[Yair]

I would personally love it if NI actually found a way to go the other way and to considerably increase the update rate (to the order of weeks) and make quick updates really easy. Ideally, this would solve the pain of having to install new LV versions, because you would simply keep updating your installed version. It would allow NI to deliver both features and bug fixes much more quickly. Alpha/beta users could test the new features and NI could use CEIP to gather usage data on new features. Those who don't want to get updates can configure the system not to do so. NI could designate specific versions as LTS versions and only release fixes for those.

 

Of course, the big concern with such a system is how to avoid breaking things with all those updates and I don't have a really good answer for that.

[Rolf Kalbermatter]

While an interesting project it looks pretty dead. No commits or any other activity in github since March 2012 after only about one year of real activity! An impressive amount of codebase but that is at the same time a problem for anyone else but the original creator to pick it up again.

 

I don't necessarily consider Java to be bad even though it is not my preferred programming language. But things like plugging in LLVM for native code generation would be pretty hard that way.