Comments URL: https://news.ycombinator.com/item?id=45943366

Points: 3

# Comments: 1

* Perspective of what it’s like working in other engineering disciplines.

* A clear and shared definition of what “engineering” is.

* Experiences shared by people who do apply significant math and science to their software authorship.

What's a straightforward way to combine a bunch of numbers? Just keep multiplying them to get a resulting volume in an ever-higher dimensional space.

t-do.com

There are still many rough edges, but it’s extremely useful. One of the best features that a text file has that very few apps support is unlimited sub-task nesting, and that’s a core feature of T-Do.

Per Kmett’s original talk/video on the subject, I can confirm my brain shifted pretty quickly to look at them like OOP field accessors. And for the three above, the mnemonics are effective:

“^.” is like an upside down “v” for view.

“.~” looks like a backwards “s” for setters.

“~%” has an tilde so it’s a type of setter and “%” has a circle over a circle, so it’s over.

I’ll also add that my experience in recent versions of PureScript things get even nicer: visible type application lets you define record accessors on the fly like:

foo ^. ln@“bar” <<< ln@“baz”

“.” Is unfortunately a restricted character and is not the composition operator like Haskell, but I alias “<<<“ with “..”

The pretty obvious question with the above is: why don’t you just write “foo.bar.baz”. In my case I use a framework that uses passed lenses for IoC, but I think “%~” is always nicer and less repetitive than the built-in alternative.

Getting more developers creating more models that can then be run on those services will likely expand business for all of those vendors.

Comments URL: https://news.ycombinator.com/item?id=43881029

Points: 2

# Comments: 0

To me the former is tolerable, the latter is not.

> I’m controversially writing our autorouter in Javascript. This is the first thing people call out, but it’s not as unreasonable as you might expect. Consider that when optimizing an algorithm, you’re basically looking at improving two things:

> Lowering the number of iterations required (make the algorithm smart) Increasing the speed of each iteration

It may be true in this domain, I wouldn’t know, but applied to software engineering in general IMO it would be a massively incorrect assumption to say choice of language doesn’t affect speed and needed number of iterations.

Comments URL: https://news.ycombinator.com/item?id=43432458

Points: 3

# Comments: 0

We don’t need better language tools. Better parsers can, and already have, been implemented in libraries.

I’d have a look at parser combinators.

Our analogies and intuitions are based off of our macroscopic experienced reality, this seems to be an entirely emergent phenomenon based on those strange behaviors described by quantum mechanics. If those insights ever do come, I don’t believe they’ll correspond to anything prewired into our brains or experienced in our lives, and will never be remotely satisfying.