undefined | Better HN

0 pointsdarkmighty9y ago0 comments

It's not unthinkable that a language, by design, facilitates or enforces precise definitions.

As a far-fetched example, think of Lego. You can't "fail to compile" your Lego bricks. You have a finite selection of bricks (all clearly visible and usually available within arm's reach), and your job is to just lay one at a time. Given any brick, it's "obvious" to a human how it fits with other bricks. The worst you can do is essentially create a crappy Lego design. As you noted going from a rough thought of

"Uhm I want to build a Dragon of about this size..."

to a finished build requires a powerful AI. But we don't need to go that far to be better than

"Place $brick1 in p=(32,17) at orientation o=(0,pi); place $brick2 in p=(38,15) at o=(-pi,0); ..."

The rigidity of the bricks inherently prevent you from overlapping them, but not the above declaration :)

0 comments

4 comments · 2 top-level

xj99y ago· 2 in thread

Not at all. Good tools are very important, and we shouldn't stop working to make them better. What I disagree with is the idea that good enough tools can replace engineers without them becoming General AIs. Until we get to that point, there will be systems that need to be built that only professionals are qualified to work on. I'm not saying that we need licensing boards or any of that nonsense, just that nobody is going to merge poorly constructed code into an important project.

darkmightyOP9y ago

I don't think it was implied good enough tools can replace qualified engineers. But I feel sometimes engineers don't realize that tools can not only be valuable for beginners (itself worthwhile, imo) but actually make experienced professionals more reliable (less error-prone) and work faster.

Taking the Lego analogy further, even if I, an experienced Lego builder, can construct a set entirely in my head, and write a correct assembly script, building it physically is likely faster and certainly less error-prone.

Those kinds of goals are hard to achieve with software (especially considering what we have is already pretty good!), but I think they're a worthy pursuit.

Examples of language/interface design that seem strictly beneficial: (regardless of experience or project)

- Showing the result of [valid] code changes as soon as possible (a feedback problem);

- Disallowing invalid expressions (a consistency problem);

- Displaying relevant components (functions, libraries, APIs, variables, etc) (a visibility problem);

- Bringing documentation closer to code (making functionality obvious)

Eve tries to tackle some of those challenges, especially the documentation problem and the visibility problem.

Solving those issues can both improve productivity and bring more people into programming.

xj99y ago

Okay, but who is your customer, the engineer or the layperson? At a certain point, our needs are going to pull in separate directions. Simple is good, but certain problems have a baseline of complexity that can't be eliminated. Who are you planning to side with?

taeric9y ago

You would be surprised how non obvious Legos actually are to people not familiar with them already.

This is akin to thinking doors are intrinsically intuitive. There is actually a ton of training that kids go through for that "intuition."

j / k navigate · click thread line to collapse