As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I work with many different models and simulations. Some of the older models and simulations are written in FORTRAN. Some of those models have been converted to C++, but the current trend is to create these models using MATLAB/SIMULINK. From a computer science perspective I have always felt MATLAB/SIMULINK was not a good solution. What language do you use to create models and simulations and why?
I would always try to use the language that is provided by the best modeling and simulation tool (or library, if you like) to do the job for me.
And this question can really only be answered by taking into account what kinds of models you want to implement. Continuous (e.g. ODEs), discrete (e.g. StateCharts, Petri Nets), or a combination (i.e. a hybrid model, as can be implemented with Simulink+StateFlow)? There are various tools for each kind of model.
Another important aspect would be the domain in which you are working. Simulink has pretty extensive libraries for electrical engineering, finance, or computational biology (most of them are included in additional packages, though) - if you work in one of those fields, there might simply be no better (i.e. complete, valid) component library. The same goes for other commercial simulation packages, such as AnyLogic, Arena, etc. There might also be some open-source simulation tools, depending on your modeling problem.
Finally, you might prefer a specific programming language over another, and you might have additional requirements, e.g. support for
Optimization (of model parameters)
Validation
Output analysis (statistics, plots, statistical tests)
Support for parallel and distributed simulation
Model checking
...
So I'm currently working with Java with the well-known advantages - reasonably fast, good support for multi-threading, relatively simple to use etc. But if 'reasonably fast' is not fast enough, there might be no option but going down one level of abstraction :-)
I also work with a lot of legacy code, most of it in Fortran. I really don't mind using Fortran - all the modern compilers allow variable names greater than the old and silly 6 character limit. Also, with Fortran 95, you can even do OOP if you feel that your modifications to the existing codebase would benefit.
Also, there are very good code editors for Fortran, which isn't always the case for more specialized script languages.
C++ has the great disadvantage of memory considerations. I have been programming C/C++ for 20+ years now, and I still forget to delete objects and properly fill in destructors.
On a final note, if you're using Windows, there is a Fortran.NET compiler (I think from Lahey-Fujitsu?) if you want to move your Fortran to a managed environment.
Good luck!
SIMULA of course !! :-)
What I've gotten out of MATLAB is it's ability to let me quickly prototype an algorithm. I can really get a good feel for the data by plotting it and using the built in statistics functions. When trying something new out, I can do something quick and dirty to get some initial results, then go back and clean things up to refine my results. With compiled languages, there's a lot more I have to do just to get the simulation to run. With MATLAB, I spend more time thinking about the real problem, and less about compiling, linking, memory management, etc.
However, there are many problems that MATLAB is just ill-equipped to solve. For large data sets, a compiled language with user defined data structures is almost certainly necessary.
Particle physics has been moving to C++ and python. This is not universal, and probably wouldn't even be close were it not for the ubiquity of ROOT.
Root's use of cint means you needed bother with memory management when you're dinking around with a new idea, it's capacity to run compiled allows you to have speed, the ability to mix the modes is very helpful, and the bindings for python and other RAD languages allow for great flexibility.
In a very real sense, this comes down to an endorsement of roland's point.
you can use s-funcuin block for linking fortran(c,c++) with matlab.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I know that Powershell is generally considered the IT management language for windows, but why/when would you choose F# instead, which is strongly typed and 'intellisensed' ?
I'd choose F# when it was a better fit for the company I was working for, the team who'll be using it, and the task at hand. Otherwise I'd choose something else.
I can't be more specific than that without more details, but I can suggest a few questions you should ask:
What is the problem you're solving?
In which language is it easier to express the solution to the problem?
Are existing staff F# developers themselves (i.e. consider the learning curve involved)?
Will the people maintaining this code be administrators (who are usually quite familiar with Powershell, & not at all familiar with F#)?
A related hint: don't allow a profusion of languages to develop in your production code and infrastructure.
By all means experiment to find the best language to solve the problem you're having, but if you find in five years time that someone has written a core component of your solution in a language that is no longer understood by anyone in the company, you may have a serious problem on your hands.
My personal rule of thumb (of course there are exceptions) is that a project should have a core language and a scripting language to hold it all together, & that those languages should be chosen first to fit the problem domain, and secondly to maximise proficiency across the team. 'Pet languages' should be strongly discouraged in production code or infrastructure.
It depends on your problem and on who will maintain the scripts.
PowerShell is very strong in administration areas (working with files, active directory, csv/xml, computers, etc.), but it's programming abilities are quite limited (e.g. case of generics). Threading in PowerShell is not as easy as it could be. But nobody expects from administrators that they will use threads. Instead there are background jobs that satifisfy administrator's needs.
On the other hand, F# is real programming language, which means it is quite low level and therefore verbose (compared to PowerShell). Some tasks written in PowerShell are one-liners, whereas in F# you would write a lot of code. Besides that - how would you achieve running command on remote computers (Invoke-Command -computer myserver ...)?
As you see, it depends on your problem.
Very important is also who will maintain the scripts. You might be on holiday and your colleagues will need to edit the scripts. Both languages need some time to learn. IMHO it is easier to learn PowerShell; thinking in functional style needs to bend your head.
It is probably a bad idea, at this point in time, to choose to write scripts in F# if they might be needed by anyone other than yourself ...
The cadre of F# speaking people is very small, so you're creating scripts which very few people can read or edit.
The fsi executable doesn't come with the .Net Framework, nor is it part of the F# runtime redistribution package (as far as I can tell). This means the scripts can only be executed where Visual Studio with F# tools have been installed.
The obvious exception, of course, is if you're a developer working on a project where F# is a primary language, since that will mean that everyone that matters will be able to run and edit your scripts.
However, I have to say that I think even in this ideal/exceptional case, it would probably be more work to use F# if your scripting task involves tasks for which there are pre-existing cmdlets in PowerShell (ie: filesystem tasks, registry, database maintenance, active directory, exchange, the list goes on and on). Of course, you might still choose to do it if you're using these scripts as an opportunity to learn the language, but bear in mind points 1 & 2 ;-)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm starting to understand Scala and I like it a lot.
How can you position yourself to get a paying job as a Scala developer (assuming those become more common)?
What parts of the Scala ecosystem have the best job potential (Lift, Actors?).
How can you gain credibility with a prospective employer without being able to point to Scala work experience (maybe experience on open-source projects?).
(The above questions are hopefully of somewhat general interest to Scala folk. If you want to factor my particular situation into your response, here are a few details about me: longtime developer (mostly Java) with a Computer Sci PhD; not currently working; I'm tied to a non-cutting edge location (Rochester NY), so I may be limited to remote work.)
Update 2010/07/30:
Thanks for the responses. I'd like to crank up the emphasis on the location issue. I'm tied by family to a location that probably won't have Scala work locally for a long time. Are there realistic prospects for getting remote Scala work, and if so how do you position yourself to get remote work? (A modest amount of travel would be doable, but not a full-on road warrior.)
Also, I was wondering about leveraging my teaching background. Would teaching a Scala class at a local university make a big difference in one's marketability as a developer, or just divert more effort than it is worth?
Pure Scala position:
Finding a pure Scala position is not very easy, but it is getting easier and easier. I am going on my first pure Scala job interview in a few days.
I hope we will see a lot of new systems being written entirely in Scala, and I think these systems will be mostly back-end, heavy duty systems. These systems will be using Scalas less error prone functional style to reduce bugs. I think Akka, SBT and Specs will be important frameworks for the Scala developer (this is not much of a prediction since they are already important).
If you do not find a pure Scala position:
Your credibility comes from your time with Java. Most big companies have heaps of Java code that must be maintained and developed. If it is your job to babysit the old Java code, and as an old Java guru, you should have some say in how this should be done. The first step is to change the Maven setup to allow mixed Java/Scala environment. Moving to SBT is probably your best choice. This is a one time investment you have to do or else you can not proceed!
If you work independently you could probably replace Java with Scala whenever you feel like, most likely when you have to re-factor some old code. Talk about Scala as a "framework" for Java (this is technically a lie) that boosts productivity when speaking to the non technical project manager, this might calm their worrying minds. In the end it will be your responsibility to see to it that Scala indeed integrates with Java. But since Scala does this very well it is not much of a problem. Actually, maintaining old legacy code is not a dream for anyone, so PMs are usually happy if they find anyone who would do it for more than 3 month. Management will probably put up with you rebellion.
If you work in a team it is a bit more tricky. In this case you have to teach the team Scala, or else they will not be able to understand your code. You have to persuade your PM to set aside resources for Scala training (might be hard). When you introduce Scala to a team, start small. My experience is that it takes a while for a Java dude to learn Scala, so this is not done overnight. Therefore, ignore everything that is "hard" when you teach Scala. When the team grasps the basics, start with writing tests in Scala (thank Davetron5000 for this tip), continue to use Java for programming in the application (the production code). Hopefully the team will learn and enjoy Scala and after that, well, it is all downhill from that point.
Good luck!
If I was hiring at the moment, I can tell you right now what questions I would be asking and they would be about the language. It is a hard language to understand at a deep level, even if it seems easy to use and, as a consequence, you might be expected to understand code written in a large number of different styles.
Knowledge of libraries (Akka and Lift being the obvious ones) the sbt build tool is great but it is an extra. I would want to know that you understand:
a bit (well, a lot) about the type system (and higher-kinded types)
something about the typeclasses approach
implicits and the pimp-my-library approach
good scala style (i.e. idiomatic scala)
recursion
the actors approach to concurrency
the standard libraries
functional programming
If you understand the language, you'll pick up the libraries with no problems, I'm sure.
Other libraries:
scalaz for functional programming
scalala for numerical programming (linear algebra etc)
scalaj for interacting with Java
I think your best bet is to get good at Scala and to get visible in the Scala community. These are not necessarily the same thing but luckily they are very closely related in the Scala community. Once you do this there are definitely opportunities to use Scala for fun and profit, whether as a consultant/contractor or as a (remote) full-time employee. As part of getting better and more visible I would recommend becoming active in one of the existing communities (Lift, Akka, ScalaNLP, you name it) or even going out in the wilderness and hacking away to solve a common problem, even if it's just making a native Scala alternative to a popular Java library (e.g. squeryl and Dispatch maybe weren't necessary but they're awesome).
I guess what I'm saying is that contributing to any good, useful Scala code will be good experience and I think the ecosystem is so young that there's no need (or benefit?) to specializing in only one part of it. Of course, if there's a specific subject that Scala is useful for and/or a specific field that benefits from Scala that jumps out to you, direct your attention in that direction.
Having had two full-time Scala jobs at this point, I'd say that the most important thing to do is learn the type system and the standard libraries inside and out. The individual technologies can then be picked up with relative ease.
Also, start using Scala (specifically Specs and ScalaCheck) for testing in your current project, today, if you possibly can.
Finally, as pr1001 said, get visible in the Scala community. Contribute to a project, interact on the mailing list, hang out in #scala on freenode, answer questions where you can.
Take your current job, and implement resume driven development. Just claim that xyz can't get done on schedule without Scala, and then use it. After that, take your project to success and either work elsewhere, open your own business, or continue developing Scala apps at your own company.
It worked for Dick Wall, so it should work for you. :)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
As a student teacher I am very interested in how effective "mini languages" such as Scratch, Logo, Alice and Lego mindstorms are in teaching the pupil the core concepts of programming such as variables, functions and loops.
Is one "mini language" better than another for teaching these basic core concepts?
Depending on how young the kids you are teaching are I would just go with a simpler language like python.
Here is a free book that teaches all the basics and is only about 200 pages long:
http://www.greenteapress.com/thinkpython/thinkpython.html
This is a very difficult question. Logo and Smalltalk (to name only two obvious examples) were both originally designed specifically for use in teaching children to program. You quickly run into a problem though: it's hard to define a language that's both simple enough for a small child to understand completely, and still rich enough to avoid its quickly becoming limiting and clumsy.
At least from what I've seen, most attempts have worked out poorly in both respects. Just for example, most attempt to include verbosity intended to make the code read more like English (e.g. the "To:" in Logo). Children often have poor enough keyboarding skills that such verbosity is frustrating. They also (in my experience) expect that if part of the syntax looks like English, that the language should accept other valid English as well (I'd expect the same is true of native speakers of other languages, but my experience is primarily with English speakers).
At the same time, most children (that I've worked with) quickly get to the point that they find the mini-language limiting. Some of that probably stems from the frustrations mentioned above. Some probably also stems from lack of imagination on the part of (at least some of) their teachers in coming up with exercises that are interesting and challenging. I think it's also much more difficult today than it was (say) 20 years ago though -- back then, kids were excited with what they could draw with turtle graphics (for one example). Today, they're accustomed to games with photo-realistic 3D graphics, and drawing a 2D "rose" out of straight lines seems to strike a lot more of them as basically lame.
I think it doesn't matter that much which "mini language" you use. But I think you better stay with a real minilanguage and not a "real" language if you don't plan on explaining more than the basics.
When I learned the basics (with Java) I was really irritated that I had to remember public static void main without really knowing what that all meant.
So I'd choose a language with as little overhead as possible.
Which specific language to choose is really dependent on the age of your pupils.
There are quite a few possibilities, and ultimately this kind of question has a lot to do with "taste." I do think that scheme is a really good choice though, for a couple of reasons. One is that it is a very minimalist language, with very little in the way of syntax to complicate things. Another is that I feel like scheme expresses something really fundamental about computation, and does so very clearly. Another is that Scheme can be used in a very "multi-paradigmatic" fashion. You can do functional programming in Scheme, or imperative programming. It's also really easy to build an object system from scratch for Scheme- you can graft a simple one onto the language in less than 100 lines of code. There are also some Scheme implementations out there that have a lot of libraries, so you can do things like graphics programming or web programming in it.
And finally a great deal of attention has been devoted to developing good pedagogical materials in Scheme. "The Structure and Interpretation of Computer Programs" is justly considered a classic, but a lot of the material in it would be pretty tough for young children, I think (it was targeted at incoming freshmen at MIT.) But there are also much gentler materials, like "How to Design Programs": http://www.htdp.org/ One thing you can see really clearly in htdp is how the minimal syntax of Scheme allows you to get right to the important ideas.
The main downside to Scheme as a first language is that most of the languages that are really widely used these days don't look much like Scheme, so students might have a bit of an adjustment in store when moving to them. But I tend to think that, particularly for kids, getting the core ideas is the most important thing at first.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
This is marked as a subjective question, I hope I won't get too many down votes though.
LV seems to offer a nice graphic alternative to traditional text based programming. As I understand, it's not a just-virtualization/data acquisition programming language. Nonetheless, it seems to have that paradigm pegged to its creator's name.
My question comes up because it doesn't seem to be widely used for multi-purpose applications. I'm not a LV-expert of any kind, I'm more like a learner. I'm still getting used to LV.
Labview is fantastic if you have National Instruments hardware, and want to do something like acquire, plot and log the data.
When you start interfacing to custom devices the wiring between modules gets complicated having to do all the string manipulation work for input and output to a device.
At my place of work, we found that we got annoyed with having to make massive, complicated VI's to interface to devices and started writing them in .NET and interfacing them to Labview.
In the end we ended up scrapping Labview all together and using the NI Measurement Studio for Visual Studio to give us all the lovely looking NI controls (waveform plot, tank, gauges, switches etc) with the flexibility of C#.
In summary, even with a couple of 24" screens, sometimes the wiring for Labview code can get too complex and becomes impossible to comment, debug, and make extensible for any future changes. I suggest taking a look at Measurement Studio for Visual Studio and using your favourite .NET language with the pretty NI controls.
My two experiences with "graphic alternative[s] to traditional text based programming" have been dreadful. I find such languages to be slow to use, hard to edit, and inexpressive. Debugging them is a nightmare. And they offer no real advantages.
To be sure, it has been quite a long time since I looked at one, but the opinions of others I've asked about them have been only luke warm, so I have never taken the time to look again. Reasons to look again are welcome and will be taken on board...
Labview can be used to author large, complex software projects. Labview is unquestionably much more fun to use than a syntax based language. I have programmed mathematically dense, dynamic simulations using labview. Newer versions of Labview include alot of exciting features, especially for utilizing multiple processors. I like Labview very much. But I don't recommend it to anyone.
Unfortunately, it's an absolute nightmare for anything other than simple acquisition and display. It may one day be sufficiently developed to be considered as a viable alternative to text based languages. However, the developers at NI have consistently opted to ignore the three fundamental problems that plague labview.
1) It is unstable and riddled with bugs. There are thousands of bugs that have been posted to the labview support forums that are yet to be fixed. Some of these are quite serious, such as memory leaks, or mathematical errors in basic functions.
2) The documentation is atrocious. More often than not, when you look for help with a labview function in the local help file you'll find a sentence that merely restates the name of the item you are trying to find some detail on. e.g. A user looks up the help file on the texture filter mode setting and the only thing written in the help file is "Texture Filter Mode- selects the mode used for texture filtering." Gee, thanks. That clears things right up, doesn't it? The problem goes much deeper in that; quite often, when you ask a technical representative from national instruments to provide critical details about labview functionality or the specific behavior of mathematical functions, they simply don't know how the functions in their own library work. This may sound like an exaggeration, but trust me, it's not.
3) While it's not impossible to keep graphical code clean and well documented, Labview is designed to make these tasks both difficult and inefficient. In order to keep your code from becoming a tangled, confusing mess, you must routinely (every few operations) employ structures like clusters, and sub-vis and giant type defined controls (which can stretch over multiple screens in a large project). These structures eat memory and destroy performance by forcing labview to make multiple copies of data in memory and perform gratuitous operations- all for the sake of keeping the graphical diagram from looking like rainbow colored spaghetti with no comments or text anywhere in sight. Programming in labview is like playing pictionary with the devil. Imagine your giant software project written as a wall sized flowchart with no words on it at all. Now imagine that all the lines cross each other a thousand times so that tracing the data flow is completely impossible. You have just envisioned the most natural and most efficient way to program in labview.
Labview is cool. Labview is getting better with each new release. If National Instruments keeps improving it, it will be great one day as a general programming language. Right now, it's an extremely bad choice as a software development platform for large or logically complex projects.
I **have been writing in LabVIEW for almost 20 years now. I develop automated test systems. I have developed, RF, Vison, high speed digital and many different flavors of mixed signal test systems. I was a "C" programmer before I switched to LabVIEW.
It's true that you can build some programs quickly in LabVIEW, but just like any other language it takes a lot of training to learn to build a large application that is clean easy to maintain with reusable code. In 20 years I have never had a LabVIEW bug stop me from finishing a project.
Back in the day, NIWEEK would have a software shootout every year. LabVIEW and LabWINDOWS (NI's version of "C") programmers would both be given the same problem and have a race to see which group finished first. Each and every year all the LabVIEW programmers were done way before the 1st LabWINDOWs person finished. I have challenged many of my dedicated text based programming friends to shootouts and they all admit they don't stand a chance, even if I let them define the software problem.
So, I feel LabVIEW is a great programming tool. It's definitely the way to go if you’re interfacing with any type of NI hardware. It's not the answer for everything but I’m sure there are many people not using it just because they don’t consider LabVIEW a “real programming language”. After all, we just wire a bunch of blocks together right? I do find it funny how many text based programmers snub there noses at it as they are so proud of the mess of text code they have created that only they can understand. A good programmer in any language should write code that others can easily read. Writing overly complex code that is impossible to follow does not make the programmer a genius. It means the programmer is a “compliator”(someone who can take a simple problem and complicate it). I believe in the KISS principle (KEEP IT SIMPLE STUPID).
Anyway, there’s my two cents worth!**
I thought LabVIEW was a dream for FPGA programming. Independent executable blocks just... work. In general, I use LabVIEW for various tasks interfacing with my DAQ and FPGA hardware, but that's about it. It seems (again to me) that this is LabVIEW's strong point and the reason it was built, but outside that arena it feels "cumbersome." As far as getting things done, it's like any other language with a learning curve - once you figure it out it's not too bad for getting work done. I've seen several people give up before that thinking the learning curve was permanent or something.
Picking up a 30" monitor made a huge difference.
I know one thing that people dislike is the version control integration.
Edit: LabVIEW/hardware is hella expensive for "just for fun" use. I dropped $10K on their hardware (student prices) and got the software for free from school for making toys around the house.
Our company is using LabVIEW for the last 10 years for measuring, monitoring and reporting of our subject (trains).
Recently we have started using LabVIEW as GUI for databases with lots of data, the powers of LabVIEW with the recent new features (Classes, XControls) allows use to create these kinds of GUIs for a fraction of development costs at other platforms. While we don't need external programmers at consultancy rate.
Ton
I first started using Labview in a college physics lab. Initially, I thought it was slow and cumbersome when compared to other text-based languages. It was too difficult to create complex logic and code became sloppy real fast (wires everywhere).
Then, a few years later, I learned about using sub-vi's and bundles. What a difference! At this point, I was using labview for very high level functions. I was taking raw input from a camera, using all kinds of image filters and processing to ultimately parse out the lines in a road so that a vehicle could drive itself down this road with no driver - it was for the DARPA URBAN CHALLENGE. I was also generating maps from text waypoint data, making high-level parsing functions, and a slew of other applications that had nothing to do with processing data from input devices. It was really a lot of fun. and FAST.
After leaving college, I am now back to using text-based languages. I've been using: PHP, Javascript, VBA, C#, VBscript, VB.net, Matlab, Epson RC+, Codeigniter, various API's, and I'm sure some others. I often get very frustrated in the amount of syntax I have to memorize in order to program with any significant speed. I find it annoying to have to switch schools of thought based on the language I am using... when all programming languages essentially do the same thing! I need a second monitor just to have the help up at all times so i can find the syntax for the same functions in different languages. I miss Labview very much, it's too bad it's so expensive otherwise I would use it for everything.
Graphical based programming I think has a huge potential. By not being constrained by syntax, you can focus on logic instead of code. Labview itself may still be in its infancy in terms of support and debugging, but I believe conceptually it beats out the competition. It's simple a more intuitive way to program.
We use LabVIEW for running our end of line test equipment and it is ideal for data acquisition and control. Typically measuring 15 to 80 differential voltages and controlling environmental chambers, mass flow controllers and various serial devices LabVIEW is more than capable.
Interfacing with custom devices can be simplified greatly by using the NI instrument driver wizard to create reusable VI's, interfacing with custom dll's if needed. On a number of projects we have created such drivers for custom hardware and once created there are reusable in future projects with no modification.
Using event driven structures user interfaces are responsive and we regularly use LabVIEW applications to interface with a database.
Whatever programming environment you choose it's the process of designing the application that matters most. I agree that you can create some really horrible and unreadable block diagrams in LabVIEW but then you can also create unreadable code in Visual studio. With just a little thought and planning a LabVIEW block diagram can be made to fit on a single 24" monitor with plenty of space to add comments.
I would use LabVIEW over Visual Studio for most projects.
But people do use LabView for purposes other than data acquisition and virtualization. Of course LabVIEW is mainly used in labs and production environments because it is (or was) one of the main NI's customer target.
However you can do a lots of various things with LabVIEW, like programming a robot that would perform a lot of image analysis, and then tweet the results. Have a look at videos from NI Week 2009 on you-tube, and you'll see how powerful this tool is. For instance, there is possibility to write code and deploy it to ARM MCUs (see this Dev Monkey article from 2009.08.10).
And finally check this LabVIEW DIY group
I have been using LabVIEW for about two years for developing automation. If given due care and proper design we sure can develop maintainable and really good looking application in LabVIEW.I think this is the same for all the other languages out there. I have seen equally bad code in LabVIEW primarily from people who use it only to develop quick and dirty working automation. IMHO Graphical programming is a lot easier to code and understand if rightly done. But that said I feel text based programming 'feels' more powerful!
LabVIEW is primarily marketed for industrial automation, has inherent support for lot of NI hardware and you can get the third party hardwares working with it pretty quickly. I think that is the reason you see it only in automation field. Moreover it is pretty costly and you are locked down with NI as you do cannot even open your code if you do not buy the software from them!
I've been thinking about this question for decades (yes, since 1989...)
Like all programming languages, LabVIEW is a high-level tool used to manipulate the flow of electrons. Unless you are a purist and refuse to use anything other than a breadboard and wires; transistors, integrated circuits and programming languages are probably a good thing if you wish to build something of any consequence.
But like all high-level tools, just wielding one does not make you a professional craftsman. Back in the day of soldering irons, op-amps and UARTs it required a large amount of careful study before you could create a system that actually functioned. The modern realm of text-based languages is so overly dominated by syntax that the programmer must get it just right before it will compile and run. In order to write code that works, the programmer must increase their skill level to create systems much larger than "Hello World".
LabVIEW is not dominated by syntax, but by Data Flow. Back in the day, reaching for your flow charting template and developing the diagram of a well-balanced information system was the art and beauty part of the job. Only after you had the reviewed flowchart in hand would you even consider slogging through the drudgery of punching out the code. (yes... punch cards)
LabVIEW is a development system that allows the programmer to use flow charting tools to diagram the complete information system and press "run"..... LabVIEW "punches out the code" and compiles it for you. No need to fight through the syntax of text language A or language B.
With such a powerful tool, novices can build large, working programs rapidly -- implying some level of professional craftsmanship since it runs at all. However, if the system does not perform elegantly, or the source code diagram is a mess, it is not the fault of LabVIEW.
People often point to "LabVIEW is only good for developing large data acquisition systems." Perhaps those people should consider the professionalism of the scientists and engineers that are working in data acquisition. If they know enough to get the actual wires right for the sensors and transducers, it may be a good bet that they are expert at developing LabVIEW wiring diagrams as well.
I do use LabView at home, as it is part of Lego Mindstorms, which my son loves. And I really like the way to compose systems like this.
However, in my work (embedded systems), it is generally to restrictive. But also here, I'm trying to move up in abstraction:
- control and state behavior: Model based design (i.e. Rhapsody)
- data algorithms etc. Simulink
Sometimes a graphical model can require more clicks than a piece of code. But this also includes the work a good programmer need to do in design & documentation; not just the code typing. The graphical notation takes many hassles away and is generally much faster if the tool is powerful enough for the complexity at hand. So I expect these kinds of tools will gain more popularity in the next years as they mature and people get familiar with them.
I have used LabView for some 10 years. It's brilliant for Scientific prorgamming ie like Matlab or Simulink but 10 times better. If you are having problems then you are doing something wrong. It takes time to learn like any language. As for using .Net instead - are these people even on the same planet? Why would you go to the trouble of writing eveything from scratch when you can say pull up an FFT etc and use alread written code. .NET is fine for simple programs but not so good for Scientific processing. yes you can do it but not without oodles of add-ons for graphics etc. Prorgamming in G is far easier than text based for Scientific problems. You can of course program in c if you are interfacing and use the dll. Now there are things that I would not use LabView for - speech recognition for example may be a bit messy at present. More to the point though, why do people like programming in outdated text form when there is an easy alternative. It is as if people want to make things complicated so as to justify their job in some way. Simplify Simplify!
Somebody said that LabView is only sued in the Automation field. Simply not write at all. It has applications in Digital Signal Processing,Control Systems,Communications, Web Based,Mathematics,Image Processing and so on. It started as a data aquisition method and they invented the name Virtual Instrumentation but it has gone far beyond that now. It is a Scientific programming language with a second to none graphical interface. It is way beyond Simulink and if you like Matlab then it has a type of Matlab scripting built in for those that like such ways of programming. It is evolving all the time. The one thing I found difficult was writing code for the Compact Rio - tricky but far easier than the alternative. It's expensive but you get a quality product. I personally have not found any bugs in ordinary programming. It is an engineers language but anybody could use it to program.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
With the interest of creating a roguelike RPG (such as Nethack, Rogue, and ADOM), which programming language would be most suitable and why?
With the language that you choose, be sure to list any libraries or facets of the language that make it particularly well-suited.
Way back in the day I tried to write Roguelike games using QuickBASIC out of all things (it was 1988.) Not the recommended approach...
There are still some development circles out there. Here's an FAQ on Roguelike Development and also a blog dedicated to the same.
My language of use (I'm trying to create roguelike too) is Python, because:
It's high level programming language, I don't need to think about memory allocation all the time, etc, but keep my mind on algorithms.
There's tons of useful libraries for almost everything. Recently I've found TDL/libtcod which can be useful for roguelike development.
With bindings you can easily use C/C++ libraries or even write few critical functions in C/C++, and use them.
It's the most readable programming language I've ever seen.
While programming in Python I've learned to use internal documentation. It's very helpful thing, I just read my code few months later and I still know what it's doing.
That's a very personal choice as always :-)
I wrote my Roguelike game (Tyrant) in Java for the following reasons:
Very portable (even with graphics)
Garbage collection / memory management
Lots of good free / open source libraries available (helpful for algorithms, data structures and manipulating save game files etc.)
It's a statically typed language - this has performance and robustness benefits which I judged to be worth the additional coding complexity
I wanted to hone my Java skills more generally for use in other projects
EDIT: For those interested it is open source, all code is available at SourceForge
Well I've made a couple roguelikes in C, spending a fair amount of time at roguebasin, which is a great site for anything related to roguelike development.
As for what language you should use, I don't really see it making a huge difference. I pick C because of the portability, and a lot of libraries work well with it.. But an object oriented language can clean up some things that you may not want to keep track of.
There aren't any languages that I would consider to be specifically greater than the rest for roguelikes. If you're making it graphical, you may prefer something that has that built-in, such as flash / silverlight. But even then there are libraries for any other languages that bring them to about the same degree of difficulty in that regard.
So I'd say take a language you know and like, or that you don't know and want to learn..
Most of these answers are great, but there's something to be said for the combined power of object-oriented stuff and low-level commands that can be abused in C++. If you're looking for some inspiration, the C sourcecode to NetHack is widely available and documented well enough that you can certainly poke around to learn some things. That said, it's a huge project that's been growing for decades, and not everything is as clean as you're going to want things for your own project - don't get roped into making poor design choices based off of what you find in NetHack.
Honestly, though, in terms of what you use it probably doesn't matter at all - though I'd highly recommend using an OO language. There's so much crap to handle in a roguelike (heck, any CRPG really) that OOP is the easiest way of staying sane.
The original nethack was written in C, and the source is available if you want to get some ideas about how it was written, and the challenges you may find which might be a good way to start deciding on a language.
My first question would be whether the game is going to have a web based UI or be some kind of console/window affair like the original Rogue-like games? If the former I would say that any language you're comfortable with would be a good choice. Ruby on Rails, Python/Django, PHP/CakePHP, etc. would all be great.
But if the answer is the latter, this is a game that you want people to be able to download and install locally, I'm going to go with Java. It's a great language with no memory management for you to deal with. It achieves very high performance thanks to just-in-time compilation and optimization, and it has an extremely rich library to help you with data structures, Swing makes for some really beautiful UIs, and the 2D library allows for the most rich cross-platform rendering outside of PostScript. It also has the availability across Windows, Mac OS X, and Linux that you're not going to get from some other choices.
Finally, distribution of your application is easy via Java Web Start as well, so people can download and install the game with just a couple of clicks once they have Java and keep it on their machine to run as long as they like.
For making any game, any language will be right if :
you can use it (you are able to use it, by knowledge or if it's easy enough to learn right now for you or your team)
it produce applications that runs on your client's computer
it can easily produce applications that runs fast enough for your game's needs.
I think that for a Rogue-Like, any language you know will be right as far as it runs on you target. Performances are not really a problem in this kind of game. World generation can require high performance if your world generation is really complex though...
just go with something that will handle the low-level details for you. whatever you know should work.
hey, they can write one in javascript.
I recommend Actionscript for those games.
You could consider Silverlight.
It sits on top of C# and .Net so theres not much need to worry about memory management. With SL you'll get built in support for scene graph type rendering - culling of things not on screen, Key board, mouse events, clicks on objects etc.
There's an initial learning curve, but I find it's a great environment to work in.