Live data from Hacker News

Atlas, a hopefully better engineering IDE

atlasengineering.io

121–130 of 136 posts

Re: Atlas, a hopefully better engineering IDE

#121
post #102

Earlier quoted context omitted.

> My use of the word “so” there occurred naturally What was unnatural about the original use? English isn't exactly standardized, there are plenty of dialects in which "so" is a common way to start a sentence. It might not be part of what you perceive as the prestige[1] dialect, but it's still natural. [1]: https://en.wikipedia.org/wiki/Prestige_(sociolinguistics)

Nothing. jchw was just querying whether I’d put it in deliberately. I didn’t; it was the wording that flowed out of my fingers (and then I decided to keep it).

Ah. That's my bad. Re-reading, and that makes more sense. Apologies for taking such a hostile interpretation.

Re: Atlas, a hopefully better engineering IDE

#122
Something I think would be cool for a tool like this is to export code in various languages. Work out your algorithm in more "mathy" tool, but then spit out plain C#/F#/Python/Javascript to implement it in an app. Definitely a niche need, but I've had times where I think this would save a ton of time. This could also be useful where you have engineers who need to work similar to what the video shows, but then coders who need to implement in business software etc.

Re: Atlas, a hopefully better engineering IDE

#123

Something I think would be cool for a tool like this is to export code in various languages. Work out your algorithm in more "mathy" tool, but then spit out plain C#/F#/Python/Javascript to implement it in an app. Definitely a niche need, but I've had times where I think this would save a ton of time. This could also be useful where you have engineers who need to work similar to what the video shows, but then coders…

The problem here is that each language has different features and different strengths and weaknesses.

For example, I would have very different implementations of, say, the A* algorithm in C++ vs Python, to the point that they would not translate into each other very well

Re: Atlas, a hopefully better engineering IDE

#124

Earlier quoted context omitted.

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…

Trying to abbreviate greek variables ends up causing a lot of issues too. It's common to have both "zeta" and x,y,z in the same scope. As well as a capital and lower case zeta. And maybe a zeta prime, and some subscripts. Unless you plan well ahead, it's hard to be consistent across all parts of the code and be concise at the same time.

Trying to come up with more descriptive names isn't practical as the variables often have very complex definitions, and it'd be impossible to explain in a variable name.

Re: Atlas, a hopefully better engineering IDE

#125

Earlier quoted context omitted.

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! ;-)

Seems like many people started on this but never finished it, me too. I got carried away trying to speed up my custom grid control, and borked it up when I tried to use threads :-P.

Re: Atlas, a hopefully better engineering IDE

#126
All those things, except units, can be done in Matlab. You can just drop a file into your workspace and they'll parse it! They also have fantastic code generation support, so your "data cleanup" is actually reproducible.

And Mathematica is really good at typing equations.

I'm interested in seeing how atlas works.

Re: Atlas, a hopefully better engineering IDE

#127

Earlier quoted context omitted.

This whole convo is reminiscent of the "filler world" phenomenon - e.g. especially if I'm feeling relaxed, I'll say "Like" a lot (I lived in CA for a decade, grew up/went to school in Boston) and I've seen that especially people from Texas will get really hung up on it (ok, big state, like CA, I have double digit individual data on this from a skew of states) and I thought about applying an audio plugin to filter out…

That doesn't have anything to do with Texas; like, overusage, like, of "like" is, like, incredibly annoying. Growing up in the midwest, we were taught to not use filler words/sounds like "uhh" or "um" in general.

I get the mindset, I just don't hold that view. I also judge people that get so hung up on it, just as they judge me for saying it. Functionally, saying "like" when bridging two parallel thoughts seems reasonable enough to me.

Re: Atlas, a hopefully better engineering IDE

#128

Earlier quoted context omitted.

Isn't the "newtype" pattern something that addresses this issue elegantly? Is there something that I'm missing here?

Not really, a units systems needs to be able to combine units in a useful way, like if I typed this: radius = 15 [mm] area = pi*radius^3 force = 100 [N] def will_i_blow_up(pressure [Pa]): if(pressure > 1 [Gpa]): return "Oh no it blew up" will_i_blow_up( force/area ) should raise an error like "UnitsException, [N/mm^3] is not compatible with [Pa]". I could then look over my code and realize I should have written: area…

If you have a language that supports tagged types and can overload operators, you can basically get there. I think a language like Idris and Julia (with the right packages) should be able to support this.

Re: Atlas, a hopefully better engineering IDE

#129
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.

This is a competitor to MathCAD which is used for things like structural calculations. I've used it for traction drive calculations. Generally you're implementing equations that are defined in papers and it's really nice to be able to make them look roughly the same.

In MathCAD you can annotate them with actual snippets from the papers too. Definitely beats coding for some specific applications.

Re: Atlas, a hopefully better engineering IDE

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

Fusion 360 has tolerance parameters, that should work for you: https://knowledge.autodesk.com/support/fusion-360/learn-expl...
Post reply on HN