Live data from Hacker News

Atlas, a hopefully better engineering IDE

atlasengineering.io

51–60 of 136 posts

Re: Atlas, a hopefully better engineering IDE

#51

Earlier quoted context omitted.

Why would you say that? OSS dominating seems to me to be a phenomenon largely restricted to the software industry, probably because we like to have a hand in our own tools and can contribute . Outside of software and data science, is there any industry where the software landscape is dominated by the OSS players?

> Outside of software and data science, is there any industry where the software landscape is dominated by the OSS players? Academic publishing, maybe. Many of them rely on LaTeX, especially the mathematics journals, but even this is changing if I understand correctly—more journals are accepting submissions in Microsoft Word format.

True, but LaTeX only exists because of computer science researchers (largely Leslie Lamport from what I understand.) They had a need, and built a tool to meet that need, and the rest of the industry benefited.

There's less overlap in needs between software and mechanical engineering, for example.

Re: Atlas, a hopefully better engineering IDE

#52
post #24

Tracking units is a thing that I rarely have a use for (as a non-engineer), but when I do, I’m totally mystified by how bad almost every language is at it. F# is the only actual programming language I found that even tries. It does a pretty decent job, but even it has some disappointing holes (e.g. not being able to understand g and kg as scaled versions of the same dimension). I guess the overlap between physicists/…

I regularly use "pint" for Python: https://pint.readthedocs.io/en/stable/ I'm sure it's not as good as a true type system could be, but it works pretty transparently due to Python's duck typing.

I’ll second the utility of “pint” for anything unit or quantity related in Python.

I’m literally in the middle of writing a rate limited continuously run service wrapper around some existing one shot task code and while I initially thought about just parsing the rate definition out myself because it’s pretty simple to just split on “/“ or “per”, but after thinking through the usage scenarios I just ended up using pint to convert anything it can understand as a frequency.

So anything of the form x / time unit or x per time unit, and converting it to the appropriate scale for use by the rest of my code. A whole bunch of string matching code replaced by a one line (two if I count the defensive unit type check to prevent false positive parsing problems) that looks as simple as this…

  default_sleep_interval = (1/ureg(default_rate)).to(“seconds”).magnitude

Re: Atlas, a hopefully better engineering IDE

#53
post #21

> Write equations; not code This is a little odd to me - I generally prefer to write my math in code if its going to be executed. I find my preferences to be pen and paper (or whiteboard)> latex, so perhaps I am not the target demographic here.

We must be evil twins in opposite universes. I've always wanted to be able to code the equations the way they look on paper. I actually am quite annoyed that most languages won't let you use Greek characters as variables. To me, it just makes it easier to spot errors.

I mean I guess that makes sense for a mathematics-oriented language. Generally, literate coding would encourage you to come up with friendlier variable names as software engineers aren't mathematicians per se and code is meant to be accessible to more than just academics/mathematicians.

In particular, I see a lot of this done in machine learning python code. Lots of "z", not "zeta", etc. Pretty tough to understand as a non-researcher.

Re: Atlas, a hopefully better engineering IDE

#54
post #24

Tracking units is a thing that I rarely have a use for (as a non-engineer), but when I do, I’m totally mystified by how bad almost every language is at it. F# is the only actual programming language I found that even tries. It does a pretty decent job, but even it has some disappointing holes (e.g. not being able to understand g and kg as scaled versions of the same dimension). I guess the overlap between physicists/…

This is something that Matlab really shines at with symbolic computation. Is there really not a numpy/scipy equivalent?

Sympy[0] is the major Python package I go to for symbolic calculation, it’s been more than enough for what I’ve needed (except for a few shortcomings I found in higher dimensional symbolic geometry, but I’m not going to fault them for not having my own weird esoteric use cases covered)

0 - https://www.sympy.org/en/index.html

Re: Atlas, a hopefully better engineering IDE

#55
post #24

Tracking units is a thing that I rarely have a use for (as a non-engineer), but when I do, I’m totally mystified by how bad almost every language is at it. F# is the only actual programming language I found that even tries. It does a pretty decent job, but even it has some disappointing holes (e.g. not being able to understand g and kg as scaled versions of the same dimension). I guess the overlap between physicists/…

This is something that Matlab really shines at with symbolic computation. Is there really not a numpy/scipy equivalent?

Mathematica as well.

Re: Atlas, a hopefully better engineering IDE

#56
post #24

Tracking units is a thing that I rarely have a use for (as a non-engineer), but when I do, I’m totally mystified by how bad almost every language is at it. F# is the only actual programming language I found that even tries. It does a pretty decent job, but even it has some disappointing holes (e.g. not being able to understand g and kg as scaled versions of the same dimension). I guess the overlap between physicists/…

This is something that Matlab really shines at with symbolic computation. Is there really not a numpy/scipy equivalent?

Matlab I thought use Maple for symbolic functionality, is that not the case?

Re: Atlas, a hopefully better engineering IDE

#57
post #21

> Write equations; not code This is a little odd to me - I generally prefer to write my math in code if its going to be executed. I find my preferences to be pen and paper (or whiteboard)> latex, so perhaps I am not the target demographic here.

We must be evil twins in opposite universes. I've always wanted to be able to code the equations the way they look on paper. I actually am quite annoyed that most languages won't let you use Greek characters as variables. To me, it just makes it easier to spot errors.

Julia lets you use all sorts of Unicode characters as variable names and even as operators. It works quite well in the REPL, since it supports a TeX-like input method for Unicode characters. It's probably my favorite feature in the language, since it makes the code much more concise and expressive. (I've always hated having to step down from the mathematical beauty of LaTeX-typeset equations into the ugly reality of spelled-out Greek-letter names in a codebase that didn't support Unicode.)

However, input method support in editors isn't as straightforward, which can become a limiting factor if you have to work on a Julia codebase that uses Unicode characters and your editor doesn't make it easy to insert those characters.

Re: Atlas, a hopefully better engineering IDE

#60
post #40

Earlier quoted context omitted.

The state of the art is done in other languages now, specifically Python with numpy and extensions, R, or Julia. There was a time for proprietary systems like this but I think it has passed.

Sure, in the fields of computer science, data science, etc. However, this is not the case in more traditional engineering fields (electrical, mechanical, etc.) which tend to teach MATLAB throughout undergraduate education and subsequently rely on it throughout graduate education, research, and industry. MATLAB has some significant benefits over the FOSS alternatives, such as its first-party commercially-supported ext…

I took civil engineering. Our introductory computer science course was in javascript, but course work later was in Fortran (which I didn't mind) and then python. There was also some matlab for labs but the programming was mostly fortran. One of my professors was doing some research in spring and dampener systems and the models were all in fortran as well.
Post reply on HN