Hacker News Reader

Comment by alemhnan | Hacker News Reader

My take is that one of the main improvements in programming languages will be to reduce the gap between domain experts and programming experts.

Now we should face three cases: 1) the programmer needs to learn the domain; 2) the domain expert needs to know how to develop; 3) something in between.

Most of developing is done in 1). There are some brilliant cases of 2). I once talked with a biologist doing some multi sequence alignment that told me that some routine in C was quite slow and was far better rewrite that routine from scratch in assembly. I was quite speechless.

In order to create better programming languages we could: 1) express domains in a better way. Actually, just be able to express domains would be really cool (and not so easy). 2) provide higher levels of abstraction.

View on HN

Every programming language from the dawn of time up to the present has made that claim at some point. This time it would be different.

I think it is just a people problem. Programmers tend to seclude themselves from their customers. Whole IT departments tend to seclude themselves from their users.

When you are looking for underwater welders for the off-shore industry, what is better, teaching a welder to dive or teaching a diver to weld?

(that's a serious question with a real answer).

It is much easier for a programmer to acquire the required domain knowledge than it is (usually) for a domain specialist to learn how to program. But you can only do so if you're prepared to 'dive in'.

My guess would be the first, teaching a welder to dive.

I base that on the fact that the core value, the welds, will be higher-quality and that's more important than the diving execution.

The diving might be off, but it shouldn't be that hard to learn well enough to survive and be effective. Of course, I'm neither a diver nor a welder.

Did I win?

> Did I win?

Yep. But a drowned welder is also not much ;)

Funnily enough, I know someone who was an underwater welder. From the conversation with him, it was a multi-month certification course, so I went ahead and looked it up online.

https://www.commercialdivingacademy.com/underwater-welding.d...

That's just one program, but it appears diving is the first thing you learn.

Edit: If you look at it from the context of a normal welder, they have an understanding and control of their environment before they start welding. You don't realize it because you've been understanding your environment since you were born. To do underwater welding, you'd first have to understand how you operate in that work environment, and then they can teach you how to start welding in it.

> I think it is just a people problem. Programmers tend to seclude themselves from their customers. Whole IT departments tend to seclude themselves from their users.

My experience is that it generally has been managers shielding the programmers rather than the programmers shielding themselves.

Maybe that is a little bit of the mark right now, but wouldn't that domain knowledge be a great opportunity for a non-tech co-founder to add value to a start-up? Just guessing, but there are a lot of domains out there that are quite diffcult to learn but that are also (or maybe because they are difficult to learn) ripe to be changed by software.

I could imagine the right match of domain knowledge and the capability to learn how to develop in a non-tech guy and programming skills and the capability to learn the domain in a tech guy would be rather powerfull combination. And pretty rare one, I guess. At least for me, the actual programming part is... difficult. ;-)

On another point, this applies pretty much things like lean or six sigma, too. Both are quite usefull (or can be, that depends!), but people tend to see them as domain by itself. In practice, and that's only my personal opinion, this comes out short. If you add this to existing expertiece in a certain domain, then it works!

In order to create better programming languages we could:

3. Create another EUP paradigm. It's been 34 years since VisiCalc came out, and despite it's success, I don't see a lot of effort to get end-users to program, especially in models, like the spreadsheet, where they don't know that's what they're doing. ;)

If you're interested in that sort of thing, ping me (see profile). My company does R&D in this space.

Reply on news.ycombinator.com