Related
I am currently doing my Honours in Computer Science and taking Artificial Intelligence as a subject. As part of completing the subject I have to develop my own basic intelligent agent.
I have yet to rap my head around what I actually have to do for this project. I am not the most technically gifted programmer and I have no idea of what to do or where to start
Could someone please point me in the right direction as to where to start learning how to develop an Intelligent Agent as well as any possible idea's of what to actually do for a project?
Any VB.net references would be appreciated as well.(I know it's not the best language to develop an IA with, but due to my time constraints this is the programming language I 'feel' most comfortable with)
Thanx in advance
Well, it depends on how you define an agents. For instance a multi-agent simulation (e.g., real time systems with parallel individuals) is inherently different from agent-based modeling (usually a simulation following the discrete time, discrete event paradigms).
From your comments, I think the latter is what you are searching for. In computer science, we have quite a lot of things written already, see the list of available ABM simulation platforms/environments yourself.
I would recommend using Repast (one of the most popular environments, its previous versions also supported VisualBasic what you were searching for), or either NetLogo or Fables (they are both domain-specific languages to do ABM).
To get an overview about ABM, here is a tutorial I wrote about a widely known toy model.
I have wonder that many big applications (e.g. social websites such as facebook) are build with many languages into its platform.
They usually start with AJAX browser support, then scale down to PHP scripting, then move towards a powrful OOP technologie such as Java or .NET, and finally a primitive language to increase performance in crucial operations such as C.
My question is how should I determinate the edge of the layers between languages. When PHP, when Java, when C and so on. And the other question is if should those languages integrate in a vertcal fashion for simplicity and maintanance, or could it be cases when you decide to program on module of your app in Java and the other in native C.
What are the context variables that push me to move to a better performance language? (e.g. concurrency issues due increase of users)
Don't tell me that PHP overlaps .NET and Java Technologies. In a starter point it does, but when the network is overload you start seeing the diferences. I mean how can I achieve Multithreading in PHP as in Java with the same performance. The thing it's hard to answer my wuestion is becasue there is not so much reading about this. You maybe find some good books covering PHP, but few telling how when and why integrate different languages.
Each language was created for different purposes, Python is strong with string operations, Perl very powerful in batch scripting, PHP a very reliable application web server, C the mother of most popular languages.
Best,
Demian.
On one end of the scale, you move to a higher performance language whenever your profiling and measurements tell you that you have a bottleneck that can't be fixed with better algorithms, data structures, or other optimisation.
At the other end, you move to a higher level language (ie. more abstraction, better libraries) whenever your management allow you to do so. ;)
I believe most teams simply use what they are best familiar with.
There are also questions of licensing that can influence the decision.
That is, if you're talking about technologies that compare to each other and solve the problem on the same level (for example ASP.NET/JSF/JSP/PHP...). But you can't compare .NET with C++ for example, they are meant to solve different problems on different abstraction levels.
My criterion for any programming language is "does it help me to get the job done or does it just get in the way?" If the latter, then it's time to move on.
From an economical point of view the answer is easy: on a regular basis just look what will be cheaper. Either continue with the current technology and maybe stretch the envelope a bit more. Or switch to something new. When you compare the two alternatives the cost of the investment already done is not important anymore since you've already spent that money/effort. You only have to look ahead: cost of licenses, education, etc.
Of course this is easier said then done, but just sitting down with a few people, thinking about it, and maybe try to come up with some numbers already helps a lot. I have seen too many projects that continued with technology that really wasn't suited for the job anymore.
Also hard numbers don't tell the whole story. There will be resistance because of unfamiliar technology, experts who are losing their status, etc.
Identify the bottleneck
Solve bottleneck
Go to 1
I'm sure you can imagine that step 2 is the one where decisions like "What programming language do we use" and "where do we put the coffee machine" come into play. That's the basic rule.
I'm thinking about switching my path "slightly" by going into desktop development (VC++, MFC, C#, etc) after about 8 years within embedded telecom systems development (C, MAKE, Symbian, 100 compilers etc, etc).
My concern however is that my experience within embedded systems maybe doesn't give me much value when going into desktop development. For example that the domain specific problems and environments I've worked with for so long still doesn't give me much to negotiate salaries with since it bares little worth on the desktop.
I think this place might be good for input on this.
So, the Q:
If you disregard the obvious generic experience on programming language level, give an example of something you have learned working with embedded systems that you could reuse when working in a desktop environment.
PS:
I should note that I'm no beginner in the desktop area - since many years back all my hobby projects are focused around desktop development.
Embedded engineers in general tend to be more disciplined when it comes to validating operations and dealing with finite resources.
This can also translate into coming up with an exception handling strategy earlier on.
The quintessential example is checking the return value of malloc. I have seen very few desktop software consistently check it, but it's commonplace in embedded environments.
Discipline of having a clean, well-organized set of source-code is the key skill that translates well to the "desktop experience". -- I've noticed that the embedded projects I've written and picked up are often WAY cleaner than their desktop counterparts.
Many desktop-only developers could benefit from the experience of making a program fit in 128K of FLASH and 32K of SRAM, not to mention communicating meaningfully with a user through only an LED or two and a couple of buttons. Making that a requirement might reduce some of the endemic code bloat in the applications industry. :-)
Even if you don't switch tracks to straight application development, the embedded experience translates well to driver development, as well as to low level utilities and to long running services. All of these are also domains where the disciplines that are nearly second-nature to a successful embedded developer remain valuable.
I was a desktop developer for almost 5yrs before switching to an embedded environment.
I find working on an embedded environment more challenging as we have to deal with memory limitations, slow CPU speed, cross-compilation issues, etc.
Having learned a lot of patience, discipline and low-level intricacies, desktop development should be as easy as a walk in the park.
State machines/event driven programming on embedded systems is not that different from event driven programming on the desktop. The depth of experience you have of these coding techniques on embedded systems, especially telecoms embedded systems, should make you a great desktop programmer.
Similarly, your experience with communications protocols should transfer nicely to the desktop. Most desktop applications have some involvement with the network.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
My questions is simple!
Would you start learning Smalltalk if you had the time? Why? Why not?
Do you already know Smalltalk? Why would you recommend Smalltalk? Why not?
Personally I'm a Ruby on Rails programmer and I really like it. However, I'm thinking about Smalltalk because I read various blogs and some people are calling Ruby something like "Smalltalk Light". The second reason why I'm interested in Smalltalk is Seaside.
Maybe someone has made the same transition before?
EDIT: Actually, what got me most excited about Smalltalk/Seaside is the following Episode of WebDevRadio: Episode 52: Randal Schwartz on Seaside (among other things)
If you like Ruby you'll probably like Smalltalk. IIRC Seaside has been ported to the Gemstone VM, which is part of their Gemstone/S OODBMS. This has much better thread support than Ruby, so it is a better back-end for a high-volume system. This might be a good reason to take a close look at it.
Reasons to learn Smalltalk:
It's a really, really nice programming environment. Once you've got your head around it (it tends to be a bit of a culture shock for people used to C++ or Java) you'll find it to be a really good environment to work in. Even a really crappy smalltalk like the Old Digitalk ones I used is a remarkably pleasant system to use. Many of the old XP and O-O guru types like Kent Beck and Martin Fowler cut their teeth on Smalltalk back in the day and can occasionally be heard yearning for the good old days in public (Thanks to Frank Shearer for the citation, +1) - Agile development originated on this platform.
It's one of the most productive development platforms in history.
Several mature implementations exist and there's a surprisingly large code base out there. At one point it got quite trendy in financial market circles where developer productivity and time-to-market is quite a big deal. Up until the mid 1990s it was more or less the only game in town (With the possible exception of LISP) if you wanted a commercially supported high-level language that was suitable for application development.
Deployment is easy - just drop the image file in the appropriate directory.
Not really a reason, but the Gang of Four Book uses Smalltalk for quite a few of their examples.
Reasons not to learn Smalltalk:
It's something of a niche market. You may have trouble finding work. However if you are producing some sort of .com application where you own the servers this might not be an issue.
It's viewed as a legacy system by many. There is relatively little new development on the platform (although Seaside seems to be driving a bit of a renaissance).
It tends not to play nicely with traditional source control systems (at least as of the early-mid 90's when I used it). This may or may not still be the case.
It is somewhat insular and likes to play by itself. Python or Ruby are built for integration from the ground up and tend to be more promiscuous and thus easier to integrate with 3rd party software. However, various other more mainstream systems suffer from this type of insularity to a greater or lesser degree and that doesn't seem to impede their usage much.
Well, since you mentioned me by name, I feel I should chime in.
As I said in that podcast interview, and as I have repeatedly demonstrated in my blog at http://MethodsAndMessages.vox.com/, this is "the year of smalltalk". And having now done Smalltalk advocacy for the past ten months, I can see that it really is happening. More customers are turning to Smalltalk and Seaside, and the Smalltalk vendors are all working hard to capture this new influx of attention. More larger Smalltalk conferences are being planned. More job postings are being posted. More blog postings are being made.
If you turn to Smalltalk today, you are not alone. There are many others who are out there as well.
Edit
Well, a number of years later, I'm now recommending Dart instead. It's a great language originated by Google but now owned by an ECMA committee. It runs serverside in node.js style, but also clientside in modern browsers by transpiling to JavaScript. Lots of good books, blogs, help channels, IDE support, public live pastebin. I think it's definitely got legs... enough so that I'm writing courseware to teach it onsite or online, and I'm pretty sure there's a book or two in the works from me. And Gilad Bracha, an old-time Smalltalker is a major contributor to the design, so there's a lot of Smalltalk in Dart.
Smalltalk is a good language to learn, and the great thing is that it only takes a day to do it. It's a lot more than just an academic language. People are building huge, scalable, replicable applications handling billions of dollars. They just don't talk about it much. See, for instance, GemStone and Orient Overseas Container Lines:
A Shipping Industry Case Study.
Seaside is a good reason to learn Smalltalk, but I don't think you'll find it orders of magnitude better than Rails.
The thing that convinced me was GemStone. I really like Gemstone's GLASS (GemStone, Linux, Apache, Smalltalk, Seaside). The killer part of that is GemStone, which handles all the object persistence for you mostly without you thinking about it. Seeing some of their demos and hearing about what people are doing with GemStone reset my idea of what "big application" meant.
The part that bugs me the most about Rails is the object-relational mapping. That's nothing against Ruby because it sucks just as hard in GLORP (which handles ActiveRecord for Smalltalk), or Perl, or anything else. Mapping objects to database tables is just painful. With GemStone, thinking about the database disappears, so the work with the database disappears too. It's like a huge stone (or a troop of monkeys) is taken off my back.
> couldn't find a Smalltalk development environment that didn't cost both arms and a leg
Google - free smalltalk
Cincom Smalltalk, Squeak, GNU Smalltalk
Learning Smalltalk will give you a grounding in object oriented software development from the perspective of the man who invented OO (Alan Kay). The idea of a overlapping windowing environment came from Smalltalk.
A stumbling block to learning Smalltalk is that it is a message passing system with a strange syntax for flow control like:
i < 60
ifTrue: [ self walk ]
It has a very mature class library that has a consistency I've not seen too many places. The class library in all environments (even commercial Smalltalks) has available source which allows you to learn from the masters of the language. When programming Smalltalk, I always ask the question how is it done in the environment.
Smalltalk is generally implemented in an image which is a live environment for all the objects in your system.
The interactive debugger really seperates Smalltalk from Ruby.
Seaside is the web development framework and has given Smalltalk a new spotlight. It is a continuation based environment that allows for intra-hit debugging and a smooth Rich Client type development experience (top application flow can be designed in a single method). It's integration with script.aculo.us has been done in such a way that it is easily called from within Smalltalk.
Nigel, one quote I have is this:
Although it's now a long time since I did anything with it, I nominate Smalltalk, I still haven't come across anything quite like it for being able to transfer thoughts into computer code. It's not just the language: It's the wonderful browser environment, the libraries, and the culture of writing clear, well-designed code as quickly as anything else can crank out spaghetti. When the participants at JavaOne were extolling how Java was so much more productive than anything else, I needed a brown paper bag. Oh well, back to sorting out my classpaths... -- Martin Fowler (Software Development Magazine, Jan 2001)
I found it here.
Would disagree with the poster who reckons you wouldn’t use Smalltalk for large apps – that’s precisely where it shines. But I have created fairly groovy (note lowercase) prototype apps in under a week too.
I learned OO in ST starting in 92, incredibly glad I did so. It gave me a real background in OO. Thinking in classes. No types. ST has a real emphasis on messaging. If you want to know something send an object a message and get an answer. IMHO, the ethos and the IDE really encourage you to do the right thing with your coupling and cohesion.
In my Java day job, I’m stuck with files, generics, IDE’s like eclipse that are orders of magnitude less productive that any ST IDE. I was using ST the only time I finished a development ahead of schedule. In fact it was so productive, and we got so much reuse I had to be moved off to another project, as I had nothing to do! (Ok, maybe I could have spent time learning to estimate...)
Download squeak, find a good book and play. Only downside is that if your day gig is using Java or C#, you’ll end up wishing you could use ST. You’d get home sooner.
Chris Brooks
I recommend everybody to learn Lisp (Scheme) or Smalltalk.
Smalltalks have wonderful IDEs which you dont want to miss once you got over the culture shock. And yes, there are more than one free ones: Squeak, Dolphin, Smalltalk/X, and Visualworks (Non-Comercial).
Lisp may be even cleaner in its mathematic foundation, though.
regards
PS: actually I recommend learning both !
I do not know Ruby..
Smalltalk is a pure OO language. If you feel the need to really understand OO, and not just the simulated OO of most popular 'OO' languages (like C++, Java, etc), then I would recommend that you play with smalltalk.
In smalltalk everything is an object, with attributes, behavior and meta. In the simulations you have data types that you use in your objects.
I would say play with it, you will only benefit.
I'm totally in your shoes. Im using RoR and looking into Smalltalk land. Here's some pros & cons I find important:
Pros:
Mature & stable environment
Fast development cycle
Makes you think more and write less
Cons:
Requires different thinking
Still didn't quite grasp it
It's quite funny how I got to know about Smalltalk. It was this one thing that keept popping up in Google results when searching for Lisp and Erlang stuff. One day I checked it out and was amazed with nice windows environment. Few moments later I've found Aida/Web framework. I was hooked and started learning Smalltalk through web development with this framework.
Still not quite there, but it's so damn interesting I just can't sit still... :-) I'm having fun again.
Would not start learning it if I had the time. Why not? Because it would be more productive and lucrative financially to learn C# or Java.
On the other hand if your a hobbyist, and would like to go on an archeological dig, then I'd suggest spending some time looking at the What, When, Why and how of smalltalk by researching Alan Kay. Fascinating story and an incredible person (after all, he earned the Turning Award). Then maybe play with squeak a little to get a feeling for the language. After this you might have a newly found respect/understanding of blocks, closures, and Object Oriented principles.
I know and use Smalltalk, have for about 15 years, still maintaining it, and would not recommend Smalltalk to a friend. Why not? Employment is a good thing to have and keep getting. Although you can learn a lot from Smalltalk you can't easily turn that into gainfully being employed in this day and age.
Also, you appeared to be excited over Seaside and I would assume the Seaside/GemStone partnership. I've used GemStone for quite some time and the two together are very appealing. I hope they can get the market share and momentum required to be successful.
Don't! If you really start learning it, you might not want to programm in something else anymore ever.
This may be not true, if you are a lisp programmer.
Absolutely, learn Smalltalk! This is 2015 and Smalltalk is on the rise again, thanks to Pharo. Pharo is FREE. Pharo is evolving quickly into a powerful enterprise tool. At Version 4.0, and soon to be 5.0, it has matured a great deal in just four years!
Then there's Amber, which is Smalltalk for the web. It's also FREE and evolving quickly.
Despite Smalltalk's reputation, this is not your father's Smalltalk. Modern Smalltalk is exciting and promising.
It's true that Smalltalk jobs are not (yet) plentiful. But if enough of you aggregate to a new wave of Smalltalkers, then the industry will adapt to it and we'll see wider adoption of Smalltalk in business. The question is, do you have the vision?
I was taught Smalltalk in one of the first graduate college level Object-Orient Programming courses (circa 1988). The teacher thought it best to start was a "pure" OO langauge,before moving on to a more trendy one (we did a bit of C++ at the end of the semester).
By that measure, it's still best to start with pure OO, although these days we have Java & C#, both of which are "nearly-pure" OO -- close enough that you can get by ignoring the non-OO features of them, and limiting yourself to the Pure-OO subset of the langauges.
If you want a better understanding of Extreme Programming (and even Scrum) I'd say yes.
Why impatient Java programmers need to learn Smalltalk:
http://www.dafydd.net/archive/2010/why-smalltalk-isnt-just-another-language/
I've been a software engineer for quite a few years now. I've heard people bring up Smalltalk a few times, and certainly Smalltalk has been around since about 1980, but it's one of those languages that's never seemed to make it into the software mainstream. Sort of like Objective C, CLIPS, PL/I, etc--something you may have heard of, but something that most folks have never programmed in.
I probably wouldn't take the time to learn Smalltalk unless I needed to for a particular job. I looked at some Smalltalk tutorials and examples briefly a few years back, and it looks like it has some clear advantages for certain aspects of OO programming (like the message concept seems cool). But sadly, it is not mainstream, and doesn't seem to be gaining much momentum.
This thread has become very actual for me. I'm planning for a Software migration to a web-application. It's a database based software. I'm especially checking the alternatives
1) Rails
2) Seaside
If I can get the figures for the Gemstone/S as Database, I'll consider that also. So for me it means I have to learn Smalltalk (better) than before. Because it could be that it will be my work for the next 15 years. You would (and should not) work with software you don't like for that long ;-). I've the impression Gemstone/S is one of the "killer" applications. But persistence of Objects still is a very difficult field....
1) Yes! It's always good to learn a language. If you are going to learn a language, make it a powerful, influential language that can be learnt easily and quickly.
Smalltalk remains a pre-eminent language and environment for learning OO concepts.
It is all objects, all the way down. This makes for a really consistent approach to working.
Integers are instances of Class Integer. Strings are a collection of character objects. Classes are singleton instance objects for the class they define.
Control structures work by sending get messages to instances of Class Boolean.
Even anonymous methods (blocks of code, aka blocks) are objects.
Everything is done by sending a message to an object. The syntax can be fitted on a postcard.
The clarity of the concepts and their implementation in Smalltalk mean that you can develop ways of thought which transfer directly into Java, Ruby and C#. I expect it's true for Python, too.
It's so good for making the concepts clear that a major UK University used Smalltalk to train 5,000 people a year in object-oriented computing.
Squeak 5, has just been released. It has gained major performance increases from its new Cog/Spur VM, which features with progressive garbage-collection.
Pharo 4 has a lovely clean-looking desktop theme. The next version, Pharo 5, will be released soon. It will move to using the Cog/Spur VM, it will have about 5,000 classes in the release, and additional packages of classes are readily available from the net via the Configuration Browser tool.
Squeak 5 is performant even on first-gen Raspberry Pis, and is almost 50% faster on the new $5 Raspberry Pi zero. $99 buys you a Raspberry Pi 2, screen and case - running a mature, fully feature-complete IDE.
Leading edge research is being done on co-ordinated, distributed OO systems in Smalltalk (e.g. Naiad and Spoon).
Some of the world's largest corporate databases are run on Smalltalk - including tracking of 60% of the world's shipping containers, and trading systems in the world's largest bank.
You can use Smalltalk as a sort of super-powered CoffeeScript, writing in Amber Smalltalk and transpiling to JavaScript, running in the browser.
Squeak, Pharo, and Amber are all Free, Open-source, open-licenced languages and environments.
Squeak and Pharo provide write-once, run anywhere facilities for MacOS, Windows and Linux. (Possibly RiscOS, too).
Dolphin Smalltalk is targetted firmly at native Windows look-and-feel, and lets you compile closed .exes of your finished work for distribution to end users. Further development of Dolphin by the vendor has stopped, but it is completely functional, and, like all Smalltalks, designed to be massively extensible. (Did I mention that Pharo now has 5,000 classes, compared to Squeak's 3,000? Pharo is a fork of Squeak 3.9)
**There is a How-to guide for installing and starting Squeak, Amber, Pharo, Cuis and Dolphin at: **
http://beginningtosmalltalk.blogspot.co.uk/2015/11/how-to-get-smalltalk-up-and-running.html
The Seaside web framework runs on Squeak and on Pharo. It's a wonderful mature tool, as is the more traditional AidaWeb framework.
VisualAge, VisualWorks and Gemstone all provide enterprise-grade robust systems. Gemstone provides an infinitely scalable object database with transactions and persistence.
2) Yes - I do already use it.
I learnt it via the Open University, and was immediately productive in Ruby (a copy of the Pickaxe book and the library reference by my side). It helped me enormously with Java, and with Xerox Moo-code.
I have just returned to it to write apps to control manage and distribute responsive, massively multi-platform mobile apps.
I expect that soon I'll be re-writing my JavaScript mobile apps using Amber, too.
I don't really know what you're looking for.
If you are looking for a different language to write in, I'd think that would depend heavily on the libraries available. I know neither Ruby nor Smalltalk, but it seems likely that the most efficient way to write Ruby on Rails-sorts of applications may not be Smalltalk.
If you are looking to learn the ideas behind Ruby, this might be a very good move. I don't have anything quantitative, but I always felt better about using tools (such as language systems) if I knew more than just the tools, if I kmew the ideas behind them or how they worked.
If you want to learn different sorts of object-oriented languages, you might well want to learn Smalltalk (if it differs significantly from Ruby), something like Java or C++, and perhaps also the Common Lisp Object System.
If you just want to learn something different, Smalltalk may well be a good choice. I'd also suggest Common Lisp, and other people will doubtless have other suggestions (can you get a good Forth system nowadays?).
Yes, I'm interested in it. Tried to start once already, but couldn't find a Smalltalk development environment that didn't cost both arms and a leg.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Background
Last year, I did an internship in a physics research group at a university. In this group, we mostly used LabVIEW to write programs for controlling our setups, doing data acquisition and analyzing our data. For the first two purposes, that works quite OK, but for data analysis, it's a real pain. On top of that, everyone was mostly self-taught, so code that was written was generally quite a mess (no wonder that every PhD quickly decided to rewrite everything from scratch). Version control was unknown, and impossible to set up because of strict software and network regulations from the IT department.
Now, things actually worked out surprisingly OK, but how do people in the natural sciences do their software development?
Questions
Some concrete questions:
What languages/environments have you used for developing scientific software, especially data analysis? What libraries? (for example, what do you use for plotting?)
Was there any training for people without any significant background in programming?
Did you have anything like version control, and bug tracking?
How would you go about trying to create a decent environment for programming, without getting too much in the way of the individual scientists (especially physicists are stubborn people!)
Summary of answers thus far
The answers (or my interpretation of them) thus far: (2008-10-11)
Languages/packages that seem to be the most widely used:
LabVIEW
Python
with SciPy, NumPy, PyLab, etc. (See also Brandon's reply for downloads and links)
C/C++
MATLAB
Version control is used by nearly all respondents; bug tracking and other processes are much less common.
The Software Carpentry course is a good way to teach programming and development techniques to scientists.
How to improve things?
Don't force people to follow strict protocols.
Set up an environment yourself, and show the benefits to others. Help them to start working with version control, bug tracking, etc. themselves.
Reviewing other people's code can help, but be aware that not everyone may appreciate that.
What languages/environments have you used for developing scientific software, esp. data analysis? What libraries? (E.g., what do you use for plotting?)
I used to work for Enthought, the primary corporate sponsor of SciPy. We collaborated with scientists from the companies that contracted Enthought for custom software development. Python/SciPy seemed to be a comfortable environment for scientists. It's much less intimidating to get started with than say C++ or Java if you're a scientist without a software background.
The Enthought Python Distribution comes with all the scientific computing libraries including analysis, plotting, 3D visualation, etc.
Was there any training for people without any significant background in programming?
Enthought does offer SciPy training and the SciPy community is pretty good about answering questions on the mailing lists.
Did you have anything like version control, bug tracking?
Yes, and yes (Subversion and Trac). Since we were working collaboratively with the scientists (and typically remotely from them), version control and bug tracking were essential. It took some coaching to get some scientists to internalize the benefits of version control.
How would you go about trying to create a decent environment for programming, without getting too much in the way of the individual scientists (esp. physicists are stubborn people!)
Make sure they are familiarized with the tool chain. It takes an investment up front, but it will make them feel less inclined to reject it in favor of something more familiar (Excel). When the tools fail them (and they will), make sure they have a place to go for help — mailing lists, user groups, other scientists and software developers in the organization. The more help there is to get them back to doing physics the better.
The course Software Carpentry is aimed specifically at people doing scientific computing and aims to teach the basics and lessons of software engineering, and how best to apply them to projects.
It covers topics like version control, debugging, testing, scripting and various other issues.
I've listened to about 8 or 9 of the lectures and think it is to be highly recommended.
Edit: The MP3s of the lectures are available as well.
Nuclear/particle physics here.
Major programing work used to be done mostly in Fortran using CERNLIB (PAW, MINUIT, ...) and GEANT3, recently it has mostly been done in C++ with ROOT and Geant4. There are a number of other libraries and tools in specialized use, and LabVIEW sees some use here and there.
Data acquisition in my end of this business has often meant fairly low level work. Often in C, sometimes even in assembly, but this is dying out as the hardware gets more capable. On the other hand, many of the boards are now built with FPGAs which need gate twiddling...
One-offs, graphical interfaces, etc. use almost anything (Tcl/Tk used to be big, and I've been seeing more Perl/Tk and Python/Tk lately) including a number of packages that exist mostly inside the particle physics community.
Many people writing code have little or no formal training, and process is transmitted very unevenly by oral tradition, but most of the software group leaders take process seriously and read as much as necessary to make up their deficiencies in this area.
Version control for the main tools is ubiquitous. But many individual programmers neglect it for their smaller tasks. Formal bug tracking tools are less common, as are nightly builds, unit testing, and regression tests.
To improve things:
Get on the good side of the local software leaders
Implement the process you want to use in your own area, and encourage those you let in to use it too.
Wait. Physicists are empirical people. If it helps, they will (eventually!) notice.
One more suggestion for improving things.
Put a little time in to helping anyone you work directly with. Review their code. Tell them about algorithmic complexity/code generation/DRY or whatever basic thing they never learned because some professor threw a Fortran book at them once and said "make it work". Indoctrinate them on process issues. They are smart people, and they will learn if you give them a chance.
This might be slightly tangential, but hopefully relevant.
I used to work for National Instruments, R&D, where I wrote software for NI RF & Communication toolkits. We used LabVIEW quite a bit, and here are the practices we followed:
Source control. NI uses Perforce. We did the regular thing - dev/trunk branches, continuous integration, the works.
We wrote automated test suites.
We had a few people who came in with a background in signal processing and communication. We used to have regular code reviews, and best practices documents to make sure their code was up to the mark.
Despite the code reviews, there were a few occasions when "software guys", like me had to rewrite some of this code for efficiency.
I know exactly what you mean about stubborn people! We had folks who used to think that pointing out a potential performance improvement in their code was a direct personal insult! It goes without saying that that this calls for good management. I thought the best way to deal with these folks is to go slowly, not press to hard for changes and if necessary be prepared to do the dirty work. [Example: write a test suite for their code].
I'm not exactly a 'natural' scientist (I study transportation) but am an academic who writes a lot of my own software for data analysis. I try to write as much as I can in Python, but sometimes I'm forced to use other languages when I'm working on extending or customizing an existing software tool. There is very little programming training in my field. Most folks are either self-taught, or learned their programming skills from classes taken previously or outside the discipline.
I'm a big fan of version control. I used Vault running on my home server for all the code for my dissertation. Right now I'm trying to get the department to set up a Subversion server, but my guess is I will be the only one who uses it, at least at first. I've played around a bit with FogBugs, but unlike version control, I don't think that's nearly as useful for a one-man team.
As for encouraging others to use version control and the like, that's really the problem I'm facing now. I'm planning on forcing my grad students to use it on research projects they're doing for me, and encouraging them to use it for their own research. If I teach a class involving programming, I'll probably force the students to use version control there too (grading them on what's in the repository). As far as my colleagues and their grad students go, all I can really do is make a server available and rely on gentle persuasion and setting a good example. Frankly, at this point I think it's more important to get them doing regular backups than get them on source control (some folks are carrying around the only copy of their research data on USB flash drives).
1.) Scripting languages are popular these days for most things due to better hardware. Perl/Python/Lisp are prevalent for lightweight applications (automation, light computation); I see a lot of Perl at my work (computational EM) since we like Unix/Linux. For performance stuff, C/C++/Fortran are typically used. For parallel computing, well, we usually manually parallelize runs in EM as opposed to having a program implicitly do it (ie split up the jobs by look angle when computing radar cross sections).
2.) We just kind of throw people into the mix here. A lot of the code we have is very messy, but scientists are typically a scatterbrained bunch that don't mind that sort of thing. Not ideal, but we have things to deliver and we're severely understaffed. We're slowly getting better.
3.) We use SVN; however, we do not have bug tracking software. About as good as it gets for us is a txt file that tells you where bugs specific bugs are.
4.) My suggestion for implementing best practices for scientists: do it slowly. As scientists, we typically don't ship products. No one in science makes a name for himself by having clean, maintainable code. They get recognition from the results of that code, typically. They need to see justification for spending time on learning software practices. Slowly introduce new concepts and try to get them to follow; they're scientists, so after their own empirical evidence confirms the usefulness of things like version control, they will begin to use it all the time!
I'd highly recommend reading "What Every Computer Scientist Should Know About Floating-Point Arithmetic". A lot of problems I encounter on a regular basis come from issues with floating point programming.
I am a physicist working in the field of condensed matter physics, building classical and quantum models.
Languages:
C++ -- very versatile: can be used for anything, good speed, but it can be a bit inconvenient when it comes to MPI
Octave -- good for some supplementary calculations, very convenient and productive
Libraries:
Armadillo/Blitz++ -- fast array/matrix/cube abstractions for C++
Eigen/Armadillo -- linear algebra
GSL -- to use with C
LAPACK/BLAS/ATLAS -- extremely big and fast, but less convenient (and written in FORTRAN)
Graphics:
GNUPlot -- it has very clean and neat output, but not that productive sometimes
Origin -- very convenient for plotting
Development tools:
Vim + plugins -- it works great for me
GDB -- a great debugging tool when working with C/C++
Code::Blocks -- I used it for some time and found it quite comfortable, but Vim is still better in my opinion.
I work as a physicist in a UK university.
Perhaps I should emphasise that different areas of research have different emphasis on programming. Particle physicists (like dmckee) do computational modelling almost exclusively and may collaborate on large software projects, whereas people in fields like my own (condensed matter) write code relatively infrequently. I suspect most scientists fall into the latter camp. I would say coding skills are usually seen as useful in physics, but not essential, much like physics/maths skills are seen as useful for programmers but not essential. With this in mind...
What languages/environments have you used for developing scientific software, esp. data analysis? What libraries? (E.g., what do you use for plotting?)
Commonly data analysis and plotting is done using generic data analysis packages such as IGOR Pro, ORIGIN, Kaleidegraph which can be thought of as 'Excel plus'. These packages typically have a scripting language that can be used to automate. More specialist analysis may have a dedicated utility for the job that generally will have been written a long time ago, no-one has the source for and is pretty buggy. Some more techie types might use the languages that have been mentioned (Python, R, MatLab with Gnuplot for plotting).
Control software is commonly done in LabVIEW, although we actually use Delphi which is somewhat unusual.
Was there any training for people without any significant background in programming?
I've been to seminars on grid computing, 3D visualisation, learning Boost etc. given by both universities I've been at. As an undergraduate we were taught VBA for Excel and MatLab but C/MatLab/LabVIEW is more common.
Did you have anything like version control, bug tracking?
No, although people do have personal development setups. Our code base is in a shared folder on a 'server' which is kept current with a synching tool.
How would you go about trying to create a decent environment for programming, without getting too much in the way of the individual scientists (esp. physicists are stubborn people!)
One step at a time! I am trying to replace the shared folder with something a bit more solid, perhaps finding a SVN client which mimics the current synching tools behaviour would help.
I'd say though on the whole, for most natural science projects, time is generally better spent doing research!
Ex-academic physicist and now industrial physicist UK here:
What languages/environments have you used for developing scientific software, esp. data analysis? What libraries? (E.g., what do you use for plotting?)
I mainly use MATLAB these days (easy to access visualisation functions and maths). I used to use Fortran a lot and IDL. I have used C (but I'm more a reader than a writer of C), Excel macros (ugly and confusing). I'm currently needing to be able to read Java and C++ (but I can't really program in them) and I've hacked Python as well. For my own entertainment I'm now doing some programming in C# (mainly to get portability / low cost / pretty interfaces). I can write Fortran with pretty much any language I'm presented with ;-)
Was there any training for people without any significant background in programming?
Most (all?) undergraduate physics course will have a small programming course usually on C, Fortran or MATLAB but it's the real basics. I'd really like to have had some training in software engineering at some point (revision control / testing / designing medium scale systems)
Did you have anything like version control, bug tracking?
I started using Subversion / TortoiseSVN relatively recently. Groups I've worked with in the past have used revision control. I don't know any academic group which uses formal bug tracking software. I still don't use any sort of systematic testing.
How would you go about trying to create a decent environment for programming, without getting too much in the way of the individual scientists (esp. physicists are stubborn people!)
I would try to introduce some software engineering ideas at undergraduate level and then reinforce them by practice at graduate level, also provide pointers to resources like the Software Carpentry course mentioned above.
I'd expect that a significant fraction of academic physicists will be writing software (not necessarily all though) and they are in dire need of at least an introduction to ideas in software engineering.
What languages/environments have you used for developing scientific software, esp. data analysis? What libraries? (E.g., what do you use for plotting?)
Python, NumPy and pylab (plotting).
Was there any training for people without any significant background in programming?
No, but I was working in a multimedia research lab, so almost everybody had a computer science background.
Did you have anything like version control, bug tracking?
Yes, Subversion for version control, Trac for bug tracing and wiki. You can get free bug tracker/version control hosting from http://www.assembla.com/ if their TOS fits your project.
How would you go about trying to create a decent environment for programming, without getting too much in the way of the individual scientists (esp. physicists are stubborn people!).
Make sure the infrastructure is set up and well maintained and try to sell the benefits of source control.
I'm a statistician at a university in the UK. Generally people here use R for data analysis, it's fairly easy to learn if you know C/Perl. Its real power is in the way you can import and modify data interactively. It's very easy to take a number of say CSV (or Excel) files and merge them, create new columns based on others and then throw that into a GLM, GAM or some other model. Plotting is trivial too and doesn't require knowledge of a whole new language (like PGPLOT or GNUPLOT.) Of course, you also have the advantage of having a bunch of built-in features (from simple things like mean, standard deviation etc all the way to neural networks, splines and GL plotting.)
Having said this, there are a couple of issues. With very large datasets R can become very slow (I've only really seen this with >50,000x30 datasets) and since it's interpreted you don't get the advantage of Fortran/C in this respect. But, you can (very easily) get R to call C and Fortran shared libraries (either from something like netlib or ones you've written yourself.) So, a usual workflow would be to:
Work out what to do.
Prototype the code in R.
Run some preliminary analyses.
Re-write the slow code into C or Fortran and call that from R.
Which works very well for me.
I'm one of the only people in my department (of >100 people) using version control (in my case using git with githuib.com.) This is rather worrying, but they just don't seem to be keen on trying it out and are content with passing zip files around (yuck.)
My suggestion would be to continue using LabView for the acquisition (and perhaps trying to get your co-workers to agree on a toolset for acquisition and making is available for all) and then move to exporting the data into a CSV (or similar) and doing the analysis in R. There's really very little point in re-inventing the wheel in this respect.
What languages/environments have you used for developing scientific software, esp. data analysis? What libraries? (E.g., what do you use for plotting?)
My undergraduate physics department taught LabVIEW classes and used it extensively in its research projects.
The other alternative is MATLAB, in which I have no experience. There are camps for either product; each has its own advantages/disadvantages. Depending on what kind of problems you need to solve, one package may be more preferable than the other.
Regarding data analysis, you can use whatever kind of number cruncher you want. Ideally, you can do the hard calculations in language X and format the output to plot nicely in Excel, Mathcad, Mathematica, or whatever the flavor du jour plotting system is. Don't expect standardization here.
Did you have anything like version control, bug tracking?
Looking back, we didn't, and it would have been easier for us all if we did. Nothing like breaking everything and struggling for hours to fix it!
Definitely use source control for any common code. Encourage individuals to write their code in a manner that could be made more generic. This is really just coding best practices. Really, you should have them teaching (or taking) a computer science class so they can get the basics.
How would you go about trying to create a decent environment for programming, without getting too much in the way of the individual scientists (esp. physicists are stubborn people!)
There is a clear split between data aquisition (DAQ) and data analysis. Meaning, it's possible to standardize on the DAQ and then allow the scientists to play with the data in the program of their choice.
Another good option is Scilab. It has graphic modules à la LabVIEW, it has its own programming language and you can also embed Fortran and C code, for example. It's being used in public and private sectors, including big industrial companies. And it's free.
About versioning, some prefer Mercurial, as it gives more liberties managing and defining the repositories. I have no experience with it, however.
For plotting I use Matplotlib. I will soon have to make animations, and I've seen good results using MEncoder. Here is an example including an audio track.
Finally, I suggest going modular, this is, trying to keep main pieces of code in different files, so code revision, understanding, maintenance and improvement will be easier. I have written, for example, a Python module for file integrity testing, another for image processing sequences, etc.
You should also consider developing with the use a debugger that allows you to check variable contents at settable breakpoints in the code, instead using print lines.
I have used Eclipse for Python and Fortran developing (although I got a false bug compiling a Fortran short program with it, but it may have been a bad configuration) and I'm starting to use the Eric IDE for Python. It allows you to debug, manage versioning with SVN, it has an embedded console, it can do refactoring with Bicycle Repair Man (it can use another one, too), you have Unittest, etc. A lighter alternative for Python is IDLE, included with Python since version 2.3.
As a few hints, I also suggest:
Not using single-character variables. When you want to search appearances, you will get results everywhere. Some argue that a decent IDE makes this easier, but then you will depend on having permanent access to the IDE. Even using ii, jj and kk can be enough, although this choice will depend on your language. (Double vowels would be less useful if code comments are made in Estonian, for instance).
Commenting the code from the very beginning.
For critical applications sometimes it's better to rely on older language/compiler versions (major releases), more stable and better debugged.
Of course you can have more optimized code in later versions, fixed bugs, etc, but I'm talking about using Fortran 95 instead of 2003, Python 2.5.4 instead of 3.0, or so. (Specially when a new version breaks backwards compatibility.) Lots of improvements usually introduce lots of bugs. Still, this will depend on specific application cases!
Note that this is a personal choice, many people could argue against this.
Use redundant and automated backup! (With versioning control).
Definitely, use Subversion to keep current, work-in-progress, and stable snapshot copies of source code. This includes C++, Java etc. for homegrown software tools, and quickie scripts for one-off processing.
With the strong leaning in science and applied engineering toward "lone cowboy" development methodology, the usual practice of organizing the repository into trunk, tag and whatever else it was - don't bother! Scientists and their lab technicians like to twirl knobs, wiggle electrodes and chase vacuum leaks. It's enough of a job to get everyone to agree to, say Python/NumPy or follow some naming convention; forget trying to make them follow arcane software developer practices and conventions.
For source code management, centralized systems such as Subversion are superior for scientific use due to the clear single point of truth (SPOT). Logging of changes and ability to recall versions of any file, without having chase down where to find something, has huge record-keeping advantages. Tools like Git and Monotone: oh my gosh the chaos I can imagine that would follow! Having clear-cut records of just what version of hack-job scripts were used while toying with the new sensor when that Higgs boson went by or that supernova blew up, will lead to happiness.
What languages/environments have you
used for developing scientific
software, esp. data analysis? What
libraries? (E.g., what do you use for
plotting?)
Languages I have used for numerics and sicentific-related stuff:
C (slow development, too much debugging, almost impossible to write reusable code)
C++ (and I learned to hate it -- development isn't as slow as C, but can be a pain. Templates and classes were cool initially, but after a while I realized that I was fighting them all the time and finding workarounds for language design problems
Common Lisp, which was OK, but not widely used fo Sci computing. Not easy to integrate with C (if compared to other languages), but works
Scheme. This one became my personal choice.
My editor is Emacs, although I do use vim for quick stuff like editing configuration files.
For plotting, I usually generate a text file and feed it into gnuplot.
For data analysis, I usually generate a text file and use GNU R.
I see lots of people here using FORTRAN (mostly 77, but some 90), lots of Java and some Python. I don't like those, so I don't use them.
Was there any training for people
without any significant background in
programming?
I think this doesn't apply to me, since I graduated in CS -- but where I work there is no formal training, but people (Engineers, Physicists, Mathematicians) do help each other.
Did you have anything like version
control, bug tracking?
Version control is absolutely important! I keep my code and data in three different machines, in two different sides of the world -- in Git repositories. I sync them all the time (so I have version control and backups!) I don't do bug control, although I may start doing that.
But my colleagues don't BTS or VCS at all.
How would you go about trying to
create a decent environment for
programming, without getting too much
in the way of the individual
scientists (esp. physicists are
stubborn people!)
First, I'd give them as much freedom as possible. (In the University where I work I could chooe between having someone install Ubuntu or Windows, or install my own OS -- I chose to install my own. I don't have support from them and I'm responsible for anything that happens with my machins, including security issues, but I do whatever I want with the machine).
Second, I'd see what they are used to, and make it work (need FORTRAN? We'll set it up. Need C++? No problem. Mathematica? OK, we'll buy a license). Then see how many of them would like to learn "additional tools" to help them be more productive (don't say "different" tools. Say "additional", so it won't seem like anyone will "lose" or "let go" or whatever). Start with editors, see if there are groups who would like to use VCS to sync their work (hey, you can stay home and send your code through SVN or GIT -- wouldn't that be great?) and so on.
Don't impose -- show examples of how cool these tools are. Make data analysis using R, and show them how easy it was. Show nice graphics, and explain how you've created them (but start with simple examples, so you can quickly explain them).
I would suggest F# as a potential candidate for performing science-related manipulations given its strong semantic ties to mathematical constructs.
Also, its support for units-of-measure, as written about here makes a lot of sense for ensuring proper translation between mathematical model and implementation source code.
First of all, I would definitely go with a scripting language to avoid having to explain a lot of extra things (for example manual memory management is - mostly - ok if you are writing low-level, performance sensitive stuff, but for somebody who just wants to use a computer as an upgraded scientific calculator it's definitely overkill). Also, look around if there is something specific for your domain (as is R for statistics). This has the advantage of already working with the concepts the users are familiar with and having specialized code for specific situations (for example calculating standard deviations, applying statistical tests, etc in the case of R).
If you wish to use a more generic scripting language, I would go with Python. Two things it has going for it are:
The interactive shell where you can experiment
Its clear (although sometimes lengthy) syntax
As an added advantage, it has libraries for most of the things you would want to do with it.
I'm no expert in this area, but I've always understood that this is what MATLAB was created for. There is a way to integrate MATLAB with SVN for source control as well.