Live data from Hacker News

Atlas, a hopefully better engineering IDE

atlasengineering.io

91–100 of 136 posts

Re: Atlas, a hopefully better engineering IDE

#91

Earlier quoted context omitted.

Or we could not police people's language. "So" is a way to start sentences; like anything else, it can be overused. Just like "like", etc. There's a good podcast episode from John Mcwhorter on this "So" phenomenon. [0] TL;DL It has some interesting applications (including functioning as a discourse marker), and isn't going away anytime soon. [0]: https://slate.com/human-interest/2018/10/john-mcwhorter-on-s...

Like it or not, perception matters. Take accents as a similar and more obvious case: rural accents will often cause you to be looked down on, and so some find it extremely valuable to deliberately adjust their accent (in some lines of work, it’s pretty much essential to hone a certain accent). So it’s often worth at least contemplating such feedback, if you care about being taken seriously. (But don’t get too hung up…

I think it depends a lot on your target audience.

Engineers (at least in my locality in California) tend to prefer direct, casual language and to a great degree even have a grudge against overuse of formal language and formalities. We love things that speak to us in our day to day language.

I suppose if you're pitching a product to lawyers, then sure, bring on the notwithstanding hitherto aforementioned gibberish and I'm sure they'll feel right at home thereinafter. :)

Re: Atlas, a hopefully better engineering IDE

#93
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/…

Julia has beautiful support for adding units to your programs. The nice thing about it is that you can plug unitful numbers into any other package and do math on them.

http://painterqubits.github.io/Unitful.jl/stable/

Re: Atlas, a hopefully better engineering IDE

#94
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 have yet to see unit handling be a problem in C++, making typesafe units is a basic exercise to give to students.

Here is a good in-depth comparison of the existing libraries:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p193...

Re: Atlas, a hopefully better engineering IDE

#96
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/…

Mathematica (and I guess Alpha now) has always had good support for units and dimensional analysis:

https://reference.wolfram.com/language/guide/Units.html

Re: Atlas, a hopefully better engineering IDE

#97
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've recently written a units library for Nim [0]. It's still WIP, but it's already proven extremely useful for me as a physicist.

Thanks to Nim's strong type system and metaprogramming features, it allows for a fully compile time design, without any runtime overhead (in form of special unit objects or such things; everything is a `distinct float`).

In addition Nim's unicode support, the code even looks nice!

A more complex use case (I can link more if desired): [1]

[0]: https://github.com/SciNim/Unchained/

[1]: https://github.com/SciNim/Unchained/tree/master/examples

Re: Atlas, a hopefully better engineering IDE

#99
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/…

When I was a physics student, I would have loved a spreadsheet that tracks units, and automatically does conversions as needed. There is another huge thing that this enables: Tracking uncertainties. It would be awesome if you could not just write "10", but "10 cm ± 1 cm". Then the spreadsheet could do error propagation! Even the simplest case of non-correlated errors would be useful. Also you could have functions lik…

For a while I toyed with writing an extensible spreadsheet engine/app that would allow extensions to do that kind of thing - maybe I should dust that idea off again! ;-)

Re: Atlas, a hopefully better engineering IDE

#100
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…

Many universities are moving to Python for their engineering education.

I believe there are two reasons: 1. the popularity of Python for ML in particular, many students want to learn general skills that are relevant beyond a narrow "engineering domain". 2. Somewhat surprisingly a push from industry, where licences make up a significant chunk of the budget. I know several R&D engineers who switched over to Python, because they got annoyed that licences where not available when they wanted to work. This has changed the overall perception of Python in these companies (who previously regarded Python as a "hobby" project).

Regarding the toolboxes, in my experience quite a few are of extremely poor quality despite significant costs. To give you one example, the instrumentation toolbox is so buggy, that we essentially have to open and close instruments every time we want to send commands (otherwise we would get random freezes which often could only be fixed with a complete computer restart). This adds significant time, when we moved from matlab to python for our instrument control measurement time for a single measurement (of which we would often need >100 in one experiment) went from >5min to less than 30s.

Post reply on HN