Hacker Newsnew | past | comments | ask | show | jobs | submit | NotPhysicsPhd's commentslogin

I have been used modelica and modelica-like languages for the past few months, and I have completely been blown away by the experience.

I think the solvers are fantastic and produce better results, in terms of speed and scale, than any other method I had used previously, I was solving the DEs using either wolfram or Julia's Differential equations.

OpenModelica is a wonderful piece of software, I just wish it had a better UI, UX and error messages. Wolfram's system modeler offers an excellent experience but it is very expensive.

Recently I have been using Mathworks take on model-based languages, Simscape[1], which is great for my use case, as it integrates the whole MATLAB and simulink ecosystem. It is not modelica compatible, but it is possible to import FMUs created with modelica.

As a final note, I truly wished that Modelica was taught more in engineering and physics degrees.

[1] https://www.mathworks.com/products/simscape.html


The secret to Modelica's results here isn't the numerics but the symbolics: they always preprocess the equations to something much simpler to simulate. With Julia we have the https://github.com/SciML/ModelingToolkit.jl to bring the same kind of symbolic-numerics approaches to practice.


Chris, I agree that the symbolic processing is quite important. I've often made the argument that a purely numerical approach just can't compete because of the optimizations and insights that come out of the symbolic analysis will always put it on a better footing (curious to know if you agree). But I'd say another factor in the success of Modelica is the ability to make it approachable by non-programmers. All the graphical aspects, acausal semantics, etc. make it easy to understand for non-programmer engineers as well. This has nothing to do with the results, per se, but is I think a factor in its success.


One could say the same for a plethora of programming languages some research is needed and we don't have to resort to extreme cases.

Out of the top of my head:

- There is the Python 2.7/3.X situation still going on, then there are the several distributions of python.

- GNU's R has a similar problem

- Installing gcc on windows was (perhaps still is) a confusing mess for a newcomer.

IMO I did not find installing clojure any harder than installing Scala for instance, and yet I have never heard (anecdotal, I know) complaining about Scala.


The user above mentioned that for _them_ the installation experience of a programming language matters a lot, and that they found the installation experience of Janet superior to Clojure.

You might not share that users preference of caring about the installation experience of a PL, but arguing that this user's preference is somehow unfair because many other languages also have bad installation experiences makes absolutely no sense.


the comparison was to Janet, not Python, R, C or Scala


Isn't GCC on Windows just unzipping a zip file and adding that location to path?


Higher Education and academia;

Apparently, maybe that's more of a local thing, there are no job offerings in industry* for Physics BSc or MSc other than web development or data science, since most R&D Jobs either require experience and/or a PhD.

Although I chose Physics mostly due to my curiosity, desire to understand how things work and the romantic idea of working in large scale physics experiments or performing researched that mattered.

I soon realized, after working in different groups over 3-4 years, that academic R&D is fully driven by the publishing frenzy and scientific rigor is sidelined most of the times.

Naively, I assumed that this was mostly due to the fact that I was not at PhD-level, and thought that the academic research world was not like this.

I applied and got a PhD grant at a different institution, and to my surprise+shock nothing really changed, other than the added weight of pseudo-responsibility that was bestowed upon me.

Maybe I have been unlucky, but the work just feels empty most of the time and void of any of the "spark" that initially got me into physics(and higher education for that matter).

With that in mind, I should have pursued a CS, EE, Math degree or a professional/technical degree.

Ironically, I'm currently pursuing a new master's degree in parallel with my PhD in an attempt to pursue a job in a different area(non physics academic research/webdev/data science).

*Non-academia


Not sure where you are, but I pursued physics as well and found the exact same endpoint as you. I'm currently teaching, but there's just not the jobs for physics unless you're going to pursue a higher degree. Now, when I talk to students interested in physics, I always tell them to just do engineering and take some physics electives on the side, or to double major in something engineering related.

My most apt description for physics is "useless engineering" when it comes to jobs; a decent overlap in content, but none of the opportunities.

(I also wish I had done math; I've come to realize that's what I like about physics, outside of astro)


I would add that not only the license is quite expensive, but it has a confusing "syntax" that most often than not results in unmaintanable software.


> it has a confusing "syntax" that most often than not results in unmaintanable software

that is more that most people who program it don't put in the time or effort to program it in a professional way. personally, i do and was trained by people who did and do, and so i have seriously complex systems built out of it that are far more maintainable than other people's systems built out of python and c/c++, which are the unfortunately choices for system development where i have worked.

the point is, just like with any language, you have to settle on the (or an) idiomatic way of working in the language, and you have to be disciplined to develop modular, decoupled code. once you do so, i find that labview's dataflow paradigm actually makes it easier than most languages to develop dependable, robust, and maintainable code. the reasons that people like functional programming languages with immutability apply to labview.

people writing unmaintainable software in labview is a symptom of the people and not the language. every time labview is brought up in meetings as the target language, there is often a gut reaction by people, but to be frank, those people actually know very little of the labview language, have never used its OOP features, are not even aware of its debugging capabilities and tools, and thus, their opinion is moot. just because someone used labview in college in a trivial way but didn't like it doesn't give them a professional voice with regard to labview. all they usually want to do is develop unreliable systems using c/c++ or python because that's the "hardcore" way of doing things. and yet, it's those projects that are often pining for help in the end when things aren't working.

so yes, labview is different, but if you treat it differently, it can greatly increase your efficiency and ability to quickly turn around robust systems. i develop systems in time units of months, not years, and my software is well known to just work.

what would you say the "confusing syntax" is that leads to unmaintainable software?


You are absolutely right and I should have been clearer on my first reply.

Most of my contact with LabView code was built by people that had no professional training on it. They use it to automate "simple" scientific experiments and create visualization dashboard, since they're mostly self-taught their software needs a re-write every 3 years. Again I believe you are right, that is mostly due to the programmer not being knowledgeable about the language itself.

Regarding the syntax, most of the LabView code I've seen was built by people with the aforementioned knowledge of the language, so It is possible that I've never seen good LabView code. But I never liked the looping and conditionals.


To my knowledge, in the Netherlands and Luxembourg there is a similar situation to the one you described in Sweden, Denmark and Norway.

In Portugal you get a fellowship that covers tuition and a monthly stipend which was increased for the first time in 15 years (by 1.4%) last year. PhD fellows are not considered employees of the University and since the stipend is not really a salary you are stuck in a weird financial situation.

Despite all this, it is enough to live (around 1000 Eur) in most of the country except for the capital (due to house/rent prices have been increasing for the past 2 years at galloping rate), which is where a great number PhD granting institutions are located.

Not to pile up, I've also discovered that you can be granted a PhD fellowship for a project at an host institution that is under equipped (if has any equipment at all) for that project.


Still, what I hear from some PhD students is that even with decent pay, it's not a great career. The chances of getting tenure are tiny, academic freedom isn't what it once was, and if you enter the job market, the PhD mostly cost a lot of time without adding a whole lot of value. Unless it's in Machine Learning, maybe.


I am not familiar with the situation in in other countries, but here there aren't many job opportunities for recent engineering/science graduates other than IT consultant. I've met people that took a PhD positions just because it was decent pay and less hours when compared with most junior and mid-level consultant jobs available.

In terms of adding value, I guess it depends on both the field and what your objectives are. For example, I work in a field where no one would offer you a job unless you have PhD or some sort insane amount of experience.


Really? My impression is that there's a permanent shortage of good programmers. Although my impression is that a big part of the reason is that Dutch companies are unwilling to raise the wages of programmers; that way they create their own shortage, of course.


But there is a shortage of good programmers. By engineering/scientists in my previous comment, I meant every kind of engineer and scientist.

From my experience, IT companies only differentiate CS, electric engineers and computer engineers for entry/junior level it jobs from the rest of the engineering and scientist. Biochemists, civil engineers, physicists, chemical engineers, industrial engineers, etc. Are all the same for the HR and assume you have 0 coding skills.


Not sure about octonions. But quaternions are somewhat used in mechanics, specifically for dealing with rotations. The usage of quaternions is computationally simpler for describing arbitrary rotations in 3d dimensions.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: