@14:20 OOP was introduced in Fortran 90 (released in 1990). It's... not great, but it's there.
@coriollisАй бұрын
hello, thanks for the vid! For reference, Fortran dependency management is getting better. See, for example, the fpm package manager, in development by the fortran-lang group. Just in case anyone wants to learn more. Fortran ftw!
@LuizGustavo-fo5mr5 ай бұрын
Very good advices in general. I think that the gist is that it varies a lot depending of the field. For instance, I work usually in few-body physics and most of my colleagues uses Fortran (some work with fortran77 and some work with modern fortran). I usually use python for simpler stuff and fortran for more demanding stuff. The language of choosing really depends on the job that is given. I have some code in fortran77 and some code with more modern approaches using coarrays and whatnot. Great video!
@gabrielepicco35824 ай бұрын
I know and use many languages (Python, C#, c++...) for software of various degrees of complexity both in research and commercial field. Well, I still go back to fortran for pure numerical stuff. You just have everything you need in a very neat syntax (native array algebra, native complex numbers, coarrays for parallelization, compilers from Intel itself...). And the visual studio code support with modern fortran extension is getting very good, I love it. I often have the feeling that the problem with fortran is people refusing to use/learn its new features rather than the language itself (even if sometimes the community is a bit too conservative with new features for the new standards, wish I had a more developed exception system for example, let's hope for fortran 202Y).
@LuizGustavo-fo5mr4 ай бұрын
@@gabrielepicco3582 I agree. It has a " bad rep" because it is an older language. The modern aspects of Fortran are very interesting and actually very simple to learn. But in science, most of the time, a certain degree of pragmatism hinders our capacity to drop our trusted computational tools in favor of learning something new from scratch.
@blaisepascal39055 ай бұрын
Thank you for this great presentation, really nice. I am not sure I understand your point when you say that functional programming is limited for scientific computing compared to object oriented programming. I can't find in which case it is true. Also Julia (multiparadigm) is more functional oriented in its core than object oriented (struct instead of class for instance). So I am a bit confused. Another point: I think it might be fair to compare Makie.jl to matplotlib instead of Plots.jl. Great video anyway!
@mair855 ай бұрын
Thanks for the tips! Is there any language/software that matches Mathematica's optimization for symbolic calculation? From what I understand, theoretical physicists depend heavily on this.
@pallharaldsson90154 ай бұрын
12:33 about in static languages such as C++ supported by GCC "[needing to worry about] garbage collection" (GC), I believe it's meant that you have to throw it out (and allocate manually), i.e. you only have manual memory management, unlike in GC-based languages like Julia (and Python). Yes, true for C, Fortran, less so for C++ and Rust (RAII gives similar benefit), but you CAN add GC to C and C+ (commonly done, e.g. most web browsers do that). GC-based like Julia (or in effect when you add GC in C++) IS easier. It can have downsides that are all avoidable in Julia, i.e. it allows avoiding heap-allocations (or preallocating there) to to help with real-time or just to eliminate small (unpredictable) overhead. [About Fortran not having OOP later at 14:20, is historically true, but it actually has OOP by now in recent versions, but still probably not much used, or too idiomatic, at least in vast majority of old/current code. And not like OOP is better... there or in C++ or Python, it's not for speed, Julia does away with traditional OOP, but such can be added with packages.]
@androth15025 ай бұрын
C/C++ are certainly starting to show their age. C++ in particular looks like someone who has had too many plastic surgeries to still look young.
@demophilo12 ай бұрын
Python is similar to a markup language. If you have a problem, you say to python call the library written in another language. That means you have to learn python and a some libraries. One for calculation, one for visualization at least. You talked about the wired point syntax. Actually it is a strength of Julia.
@Seedwreck2 күн бұрын
MatLab kinda slow
@a.j.apalla8545 ай бұрын
Hey Jonathon, I’m an applied math undergrad. How did you manage to get into a physics masters? Did you do computational physics research as an undergrad?
@JonathonRiddell5 ай бұрын
I did my undergrad as a "Applied Math and theoretical physics honors double major". So I took a lot of physics courses. The most important part though was getting a research position with a physicist. Where I was (at the time) the theory physics people were mostly in the AM department.
@scientificsurrealism14895 ай бұрын
Really hope Haskell gains more attention in mathematical physics area!
@juliaifrank5 ай бұрын
Great video Jonathon! We can talk about it for a looong time 😅 As a computational physics student myself (who used Julia for the past three years for my research projects), I can only confirm your points: 1) R is not popular in physics research. 2) Python or Julia are. Then, maybe, MATLAB (especially in engineering fields). Some researchers still prefer to use C/C++. *Python*: easy to learn, very well documented, etc. Sufficient for most researchers. *Julia*: easy to learn, performance-oriented (almost all Julia libraries are written in Julia as well, Just-In-Time compiled), easy to implement distributed and GPU code (especially writing your own GPU kernels when the task at hand is super specific to your research field). If performance is an issue, and Python does not cut it, Julia is a great choice for computation-heavy programs. Now, how would Python compare to Julia in scientific ML projects? This is what I am hoping to answer next.
@JonathonRiddell5 ай бұрын
It's certainly a topic that gets people passionate! I find every department converges to one answer, my current department is very big on Julia. My previous one was all about C,C++. I think answering if Julia is good for ML is a great question. I think the Julia community would certainly like to think so, but I hear Mojo might make this a much harder discussion :).
@juliaifrank5 ай бұрын
@@JonathonRiddell Thanks for bringing up Mojo! Tbh, this is the first time I have heard about it. Now I need to read more about it.
@YaelScience5 ай бұрын
Is there a package for julia that is similar to sympy for symbolic computing (that includes ODEs and integrals)?
@juliaifrank5 ай бұрын
@@YaelScience To be honest, I do not think there is an equivalent library in Julia, that is as good as Sympy yet. Some alternatives are ModelingToolkit.jl, Symata.jl (relies on Sympy actually), and Reduce.jl. But I have not personally used them.
@andyk21812 ай бұрын
@@YaelScience There's Symbolics.jl and SymbolicNumericIntegration.jl however, last time I did symbolic computing in Julia I had to choose between calling sympy using IPython, or solving the problem using Matlab, because the native symbolic libraries had limitations around non-linear algebra.
@rubempacelli6815Ай бұрын
As a scientist programmer, I really disagree about the comments over C. Although it is not usually the way-to-go, nothing is better than C. Nothing is faster than C. Nothing is more computationally efficient than C. So being able to delegate certain parts of your tasks to C code written by you is sometimes the most reasonable choice.
@dihydroxyacetonep042 ай бұрын
Julia can call pyplot... Moreover, you get the ITensors library. Many Body Physics and Julia hands down!
@user-eo1ju3uu9x5 ай бұрын
As a computational materials scientist wanna just to thank you for this video. I hope I had seen it as I started my journey.
@alessandrorossi12945 ай бұрын
I haven't watched any of this yet, but I'm just going to say the answer is Python and it has been for at least a decade. Now I'm going to watch the video and include my commentary as replies to this.
@alessandrorossi12945 ай бұрын
OK I didn't realize this was going to be a 36 minute video. I skipped around a bit. I would have appreciated chapters so I could get a gist of what you wanted to say.
@JonathonRiddell5 ай бұрын
Once you finish you'll see that I agree for a "starter language" and for most tasks. However, a lot of computational tasks are simply too heavy for python, or fall out of the scope of things you can easily do with numpy / other packages. So I think the answer is more nuanced than just "python".
@JonathonRiddell5 ай бұрын
I've added time stamps
@alessandrorossi12945 ай бұрын
@@JonathonRiddell well there’s multiple ways from Python to interface with C code (for example the ctypes module), Fortran (through scipy bindings, see the gensim library for an example of Python code that uses the scipy Fortran bindings to actually run faster than C code), and for CUDA there’s PyCUDA which is Nvidia’s best supported way to directly interact with CUDA cores. So the answer is definitely “learn Python, and if you belong to a niche that absolutely needs more performance then you can use those options later”
@JonathonRiddell5 ай бұрын
That is indeed basically what the video says while giving a landscape for what extending your skillset might look like. Along with discussing Julia which is a viable option, and computer algebra systems.
@andyk21812 ай бұрын
The difficulty with Julia isn't the language, but working out a good developer workflow with the immaturity of the packages. There's also the case that if you're learning data science, chances are that the courses use MATLAB or Python, so you pretty much have to learn those languages anyway. I think this explains somewhat why Julia has failed to gain in popularity.
@user-rq9rl1hs4j4 ай бұрын
Python is kidding, it just for who dont no c, rust, nime and ....