Quote from dandl on August 7, 2021, 2:05 am

Quote from David Livingstone on August 6, 2021, 2:02 pm

Quote from dandl on August 2, 2021, 12:10 am

Writing code is easy, the hard things are (a) knowing what code to write and (b) getting others to use it.

I was intrigued by this statement, and there doesn't seem to have been the response to it that I would have expected.

I presume you mean that you are a skilled programmer in one or more languages, so the hard part is (a) figuring out the architecture and algorithms to be expressed by the code, and (b) determining the sort of product to be produced by the architecture and algorithms.  (b) should be solved before (a).

If so, I'd go along with you.  If not, please ignore the rest of this post and post a correction for me.

My interest stems from the fact that I got into computing by having to solve problems for which it turned out I had to use a computer, i.e. learn to program and write the software to solve the problem.  I then professionally got into Operation Research (= use scientific methods to solve management problems) which meant I did this all the time, since the problems typically had solutions solved by running software on computers.

I mention this because for me, your (a) and (b) have always been the essence of programming; whereas I'm not sure whether that is true for yourself.

I've also found that many commercial programmers seem more interested in code writing than (a) and (b).  Their concerns are typically more about the nature of the programming language they're using, and the code's physical performance.  These concerns are important of course, and essential to a good product.  I'm not deriding them.

I suppose it's just that I've learned a different attitude.

It's a sweeping statement and easy to pick holes in, but it has a key message. There are millions of competent programmers out there, just like there are millions of competent dentists, architects, lawyers and so on. It's hard to learn, but about 10 years in it's just another skilled job. And almost all of them are employees, told what code to write and what it will be used for. Life is easy.

But taking a vague problem statement or idea and turning it into working code, and then getting people to actually want to use that code is on a whole different level. That's really hard.

I've written code in over 50 languages and I no longer get a buzz out of merely writing code that works. The biggest buzz I recall was when I visited a computer show and found an exhibitor selling a product written in Powerflex (the language product my company sells). The second was signing a contract with a customer who built a billion dollar company on Powerflex. That beats the 20 hours I spent on tracking down and solving a bug in a vendor compiler we depended on by a country mile.

Quote from Dave Voorhis on August 7, 2021, 8:32 am

Quote from Erwin on August 6, 2021, 9:13 pm

...  I reckoned while writing all that stuff that readers who managed to get there would be ***genuinely*** curious and not just "mildly".  And would be ***genuinely*** willing to ***invest*** some of their time believing what they'd find would be worth the effort in the aftermath.  ...

The fact that this rarely happens is why so much of industry success relies on marketing and sales; whether products are great (or rubbish) seems largely irrelevant.

Quote from dandl on August 8, 2021, 1:08 pm

Quote from Erwin on August 6, 2021, 9:13 pm

Quote from Erwin on August 6, 2021, 5:07 pm

Quote from dandl on August 5, 2021, 3:50 am

No-one is doubting the quality of the product, the question is entirely about how accessible it is. Can a mildly curious visitor figure out enough to write a Java app with it?

 

2nd answer.  That depends on the definition of "mildly".  And also on the intrinsic ability to figure things out.  There are those in the world of psychological research who believe that a difference of over 20 IQ points (on the scale with an STDDEV of 15, that is) makes it ***impossible*** for the two individuals at hand to communicate in a way that is satisfactory to both.  I presume it's an as yet unproven assumption/thesis/... maybe parhaps something akin to P != NP ...  but if it's true it kind of sadly reduces the cardinality of the set of potential communication partners that those at some +- extreme end of the curve can satisfactorily communciate with.  I reckoned while writing all that stuff that readers who managed to get there would be ***genuinely*** curious and not just "mildly".  And would be ***genuinely*** willing to ***invest*** some of their time believing what they'd find would be worth the effort in the aftermath.  Well, misbeliefs about what other people find interesting, time-investment-worthy, you name it, are always possible, I guess.

For some definition of satisfactory.  I find that when the topic is football, rebuilding a gearbox, hiring an electrician or beer somehow the question of IQ never comes up.

My customers are experts in their field, about which I know very little. They think they know something about programming, so I listen, sell them software and help them get it working. They come to me because I'm an expert in a field and I may solve their problem. People coming to look at SIRA_PRISE are likewise experts with problems they think you might be able to solve. In my opinion it's up to you to talk to them as one expert to another, and show them how. At the very least I think you should say to them:

1. Yes, you can create a database with your data in it using SIRA_PRISE and here's how.
2. Yes, you can query that database using SIRA_PRISE as a DQL and here's how.
3. Yes, you can write applications to access that database in Java (and perhaps others) and here's how.

While we're on the subject of databases, another question I can't find on the web site: what's the underlying storage engine for SIRA_PRISE? Does it have a separate server or does it run in-process?

Quote from Erwin on August 8, 2021, 7:01 pm

Quote from dandl on August 8, 2021, 1:08 pm

 

For some definition of satisfactory.  I find that when the topic is football, rebuilding a gearbox, hiring an electrician or beer somehow the question of IQ never comes up.

There are innumerable other cases where "the question of IQ never shows up".  IT job interviews, for example.  Perhaps that's the problem.  Perhaps that's why Chris Date felt it necessary to write that article on the difference between "professionals" (let alone "experts", which is the word you used and even self-declared yourself to be one of) and "practitioners".  Writing a robust reliable and relationally complete DBMS is not the same ballgame as installing the electricity in a newly built house.  The latter gets done millions of times per year, by people that qualify as "practitioners".  The former still hasn't been achieved anywhere in the entire history of IT.  It's only been gotten "close to" for violating any of the three parts of the "robust, reliable and relationally complete" conjunction.

Quote from dandl on August 9, 2021, 1:40 am

Quote from Erwin on August 8, 2021, 7:01 pm

Quote from dandl on August 8, 2021, 1:08 pm

For some definition of satisfactory.  I find that when the topic is football, rebuilding a gearbox, hiring an electrician or beer somehow the question of IQ never comes up.

There are innumerable other cases where "the question of IQ never shows up".  IT job interviews, for example.  Perhaps that's the problem.  Perhaps that's why Chris Date felt it necessary to write that article on the difference between "professionals" (let alone "experts", which is the word you used and even self-declared yourself to be one of) and "practitioners".  Writing a robust reliable and relationally complete DBMS is not the same ballgame as installing the electricity in a newly built house.  The latter gets done millions of times per year, by people that qualify as "practitioners".  The former still hasn't been achieved anywhere in the entire history of IT.  It's only been gotten "close to" for violating any of the three parts of the "robust, reliable and relationally complete" conjunction.

Although we're getting seriously off topic,  beg to differ. When I interview for a programmer, I look for signs and ask questions that point to high IQ. When I interview for sales I look for ego and people skills, not IQ. Both are experts, but the requirements are very different.

My point is that every user/customer for a DBMS is an expert in something, just not something you care about. You need to get them to care about what you have to offer by showing them how it can solve a problem that matters to them. Give them a reason to care, or they'll just walk away.

BTW this advice applies just as much to Rel as it does to SIRA_PRISE. It doesn't (unfortunately) apply to Andl, because that was a language experiment, fun to write, but falling well short of solving any useful problem.