I don't know what you mean by "real world R&D" because that could mean anything. But as my main project has grown, here are a few tips I wish I knew when I started (some of these are scientific computing / data science centric):
1. If you're doing anything complicated with a piece of data, make it a fully featured type. If there's really one array you're accessing from it, give that type getindex and setindex commands so that it acts like an array. This will make your code much cleaner. Also, build all of the "performance-enhancement tricks" you plan on doing with it into the functions of the type itself. Spawn it off to its own package. Document and test it thoroughly. Now you have a type that will cleanly give you good performance (and you can share it with the community). I can't stress this enough: building good types is a good way to make code both clean and fast, and testing them separately makes them easy to maintain (and makes it easier to find out how to change them for the next Julia version). 2. Use multiple-dispatch to make your code more readable. Don't call your functions plot_potato and plot_carrot, just use plot and have your types work the details out on what it does. Avoid giant if elseif elseif ... by using a function with dispatches. 3. Use multiple-dispatch on short functions to give better performance. Types can be known because of dispatch. So for performance sensitive parts of code, don't use "if this type, do this, else do this", instead write a function which works that out by dispatch. This will lead to stricter typing and better performance. Then, write a good test for that small function and that functionality will be both easy to maintain and good for performance (if it's small enough, the compiler will just inline it so there anyways). 4. Use Plots.jl's plot recipes for plotting your types. They will make it so that way plotting your type is just the command plot(type), but that plot command is also infinitely customizable. Plot recipes are really quick to write, and will make it so easy to plot that you'll use plots as feedback everywhere. You can also use the UnicodePlots backend to have your tests show you plots. 5. Every once in awhile, go back and use ProfileView and @time to optimize code, cut down on allocations, and make things a little faster. I prefer to benchmark ideas before I implement them as well. Double check functions with @code_warntype or maybe peak at the @code_llvm for anything weird. 6. Use the process server option in Juno, and remember the command Ctrl+j Ctrl+k (kill the current process). The process server has extra Julia processes ready for when you kill the current process, so you can instantly be computing again without a delay. 7. Get on Gitter. You will invariably run into some issues/missing features in the package ecosystem. Asking a quick question in a chatroom can get you a known workaround in seconds. You can also ask for good repositories to learn software design from. 8. Use in-place functions whenever you can. I prefer to prototype without it, and then change things to in-place. This is because sometimes in-place functions can mean that the reference of two variables are still the same, which can be a hard to bug to find (best way to find it: print everything out and you'll see two variables have exactly the same values). My mantra usually is: get it working, and then apply all of the optimizations (and benchmark along the way). 9. Write lots and lots of tests. Let the tests tell you if something is wrong. At first this seems like it slows you down. It doesn't. 10. Start early with documenting your functions with docstrings. Documenter.jl will essentially build your documentation from your docstrings, so if they're complete then making your documentation will be simple. 11. Use Github. Even if you don't register your package / have it private, use continuous integration testing. Use branches to try out new ideas. Write your own issues to keep track of things you want to do and bugs you've encountered (maybe use the new project stuff?). Julia is designed to be used in conjunction with Github. 12. Save your "end results" by using an IJulia notebook. It will store the code and the output. It's a good way to "document" as you go along without actually taking the time to document. Of course, it's better to write fully featured documentation, but when you're prototyping, it's a good way to show someone "here's how to use it and here's what it does" (while at the same time testing your code). And lastly, 13. Don't be afraid to break the rules in parts of the code where performance isn't crucial. As long as your hot inner loops are wrapped inside a function call with strict typing (and these loops take the vast majority of your time), you can do pretty much whatever you want above it without worrying about performance. Write a larger function which fixes types, sets up plots, etc and then calls your inner loop function. This will let you be sloppy with your prototyping but will still have everything work (and be fast). I wouldn't say I write very elegant code, but after adopting these rules I have rapidly written large amounts of very fast and (what I find to be) easy to maintain code. Hope you find something in there that helps. On Thursday, September 15, 2016 at 12:11:21 PM UTC-7, Tsur Herman wrote: > > Hi , I am new here . > Just started playing around with julia, my background is in Matlab c++ and > GPU computing(writing kernels) > > I am trying to figure out what will be good practice for rapid prototyping. > How would you use Julia and Juno IDE for a research and development > project that will > end up having numerous files and many lines of code , and a basic gui? > > Please share your experience , thanks. > Tsur > > >
