Live data from Hacker News

The Minimally-Nice Open Source Software Maintainer

brson.github.io

51–60 of 61 posts

Re: The Minimally-Nice Open Source Software Maintainer

#51

Earlier quoted context omitted.

"Being nice is something stupid people do to hedge their bets." ~Rick, fictional smart a-hole. > Maybe I could put it another way. September 1993 ended, just not the way some people would have wanted it to. You could put it that way, if you wanted to be a patronizing fool. Try to understand that you are evidently one of the people I'm complaining about. You're not disagreeing with me; you're calling me a fool in a pa…

"Getting software right is important. I estimate that about 9 out of 10 people getting paid to write software today shouldn't be. You do realize that today, in 2017, most of the needful software has already been written don't you? Think about it." I'm curious if you've read the Richard Gabriel essays. Certainly the two of us have seen something like engineering of software. Anyone looking has seen high-quality softwa…

I haven't read them but I'm familiar with the area of discussion.

My argument here rests on the idea that we are late in the game of software development. Most of the software we need has been written already. What we are doing now is a thundering herd attack on the global mind-space of algorithms+data. (How many chat apps? how many serialization formats, etc.)

I am kind of off in the corner. For example, I don't see Rust lang as cool and innovative, to me it looks like a tarpit.

There is a better way.™ ;-)

Over in the "The Power of Prolog" thread https://news.ycombinator.com/item?id=14045987 there are posted three solutions to teh Zebra Puzzle. There's one in Ruby all bloody minded, one in python even longer and more bloody minded. Then there's the one in prolog I wrote after reading the docs for half the day instead of working. (D'oh! Hi boss.) The Prolog version is less than a page of code and half of that is direct translations of the puzzle hints to CLP constraints (the other half just sets up the variables and such.)

The other two aren't bad because they weren't written in Prolog. They're bad because they both would be better off implementing the resolution algorithm (i.e. mini-kanren) and then using that to solve the puzzle. It still would have been shorter and easier and faster.

Now, why didn't they know that? That's the essence of my concern.

The prolog solution is much shorter, returns the solution instantly, and I'll wager it took me much less time to type it in once I had figured out how to translate the puzzle into CLP(FD) style. Am I the 10x programmer? No. I think what I (and others) do is learnable. I've maintained for years that anyone who can solve a sudoku puzzle has the intelligence to learn to program. In fact, I've just realized that anyone who solves Sudoku puzzles already knows the resolution algorithm, that's what their mind is doing to figure out the puzzle.

So most people can be taught Prolog. The machines are vast and fast enough now. Why is everybody so keen on cracking out code, to make a buck or scratch whatever itch, but not on doing it better using tools and techniques that are hella old!? Is humanity really so perverse? ;-)

(P.S. I'm still working on replying to your kind and excellent email.)

Re: The Minimally-Nice Open Source Software Maintainer

#52

One huge problem is that September never ended... ( https://en.wikipedia.org/wiki/Eternal_September ) What I mean is, there are lots of people who are not as smart as they think they are, and they won't STFU and RTFM, etc... Send not to know at whom the Torvalds curses, he curses at thee. Frankly, I think the author's original position was correct: Emphasize credit for authors of RFCs and you'll get fools authoring R…

You cannot mention Eternal September here. It's a sore spot for HN. No one wants to know how or by whom the software is produced that makes them rich.

Re: The Minimally-Nice Open Source Software Maintainer

#53
post #34

Earlier quoted context omitted.

With one side project, I've had people almost leave the project because I was being accomodating to someone who clearly had no idea what they were doing. They were getting frustrated with the constant low quality discussion, and one ended up private messaging me to say that either $IDIOT left or they were going to go. Another probably just dropped of without saying anything. Just showed up less frequently in chat, un…

That's quite anecdotal. It might be true and work for you. I'd then ask if it's the general rule that maintainers being helpful to people who have more to learn is causing lots of problems. I doubt it given the huge ecosystems with beneficial results that came from software catering to such people. Now, it might be quite different for those focusing on extra-high quality, reliability, or security. These seem to take…

First off, at least in my mind there's a difference between people asking good questions in order to learn, and people constantly making stupid proposals without taking time to learn enough context to understand why their proposals are bad.

And, yes, of course it's anecdotal, and of course it's not universal. I don't believe my preferences for interaction should be universal. The software world is big enough that I can go join places that match my tastes, and avoid ones that don't.

Re: The Minimally-Nice Open Source Software Maintainer

#54
The Compliment Sandwich* is known to be a poor technique for providing criticism. It doesn't help the person you're criticising (people see straight through it) and it also negates the compliment. It also braces people for criticism next time you pay them a compliment.

Worse still, it distracts from the message you are trying to convey.

There is a way of being critical without making a person feel bad, by being factual and not making it personal, and by remembering that you are trying to help that person in some way.

*Btw, we brits call it a shit sandwich :-D

Re: The Minimally-Nice Open Source Software Maintainer

#55
post #6

Contributors volunteer skilled labor that can help a project be even better. The worst thing a maintainer can do is dissuade them from helping. A good rule of thumb is to assume positive intent from contributors. People who are requesting changes are trying to solve problems; rarely are they doing it for personal aggrandizement or to fulfill some philosophical mission. One thing that really upsets me when I propose c…

> rarely are they doing it for personal aggrandizement or to fulfill some philosophical mission.

Sometimes. Spending hours tweaking a CoC or changing pronouns in documentation is not solving any problems and results in unnecessary back-and-forth, flame wars, HN posts, etc.

Re: The Minimally-Nice Open Source Software Maintainer

#56
post #54

The Compliment Sandwich* is known to be a poor technique for providing criticism. It doesn't help the person you're criticising (people see straight through it) and it also negates the compliment. It also braces people for criticism next time you pay them a compliment. Worse still, it distracts from the message you are trying to convey. There is a way of being critical without making a person feel bad, by being factu…

It's absolutely a shit sandwich, the sandwich is named for whatever's in the middle! :)

Re: The Minimally-Nice Open Source Software Maintainer

#57

One thing I wish GitHub made easier is responding to a pull request with a patch rather than encouraging reviewers to type up a bunch of suggestions that the original submitter will have to turn into a patch themselves. If you have a better idea how to accomplish part of a suggested change, you can communicate that more clearly by making a patch and leaving a comment explaining why. GitHub should encourage this and a…

Not sure if it's what you had in mind. But, you could comment with a diff code fence. It gets proper highlighting as well.

    ```diff
    diff goes here
    ```

Re: The Minimally-Nice Open Source Software Maintainer

#58

Earlier quoted context omitted.

Could this be accomplished with a pull request into their feature branch?

Absolutely, and I've done that before, but the web interface doesn't really help with this. You also need to alert the original thread about it manually so others can follow the thread. If you have five different suggestions, should that be five separate PRs to their feature branch? Probably? Or they will just need to modify or rebase out the commits they don't want. Anyway, I just like all solutions where "doing the…

It would be great to have "PR patches" as something handled gracefully by the web interface. Even if they're just branches under the hood, a "click to accept this change" feature on open PRs would be a nice way to encourage simple fixes.

Re: The Minimally-Nice Open Source Software Maintainer

#59

Earlier quoted context omitted.

"Getting software right is important. I estimate that about 9 out of 10 people getting paid to write software today shouldn't be. You do realize that today, in 2017, most of the needful software has already been written don't you? Think about it." I'm curious if you've read the Richard Gabriel essays. Certainly the two of us have seen something like engineering of software. Anyone looking has seen high-quality softwa…

I haven't read them but I'm familiar with the area of discussion. My argument here rests on the idea that we are late in the game of software development. Most of the software we need has been written already. What we are doing now is a thundering herd attack on the global mind-space of algorithms+data. (How many chat apps? how many serialization formats, etc.) I am kind of off in the corner. For example, I don't see…

"I haven't read them but I'm familiar with the area of discussion." "What we are doing now is a thundering herd attack on the global mind-space of algorithms+data."

Nice way to put it. Ok, you really need to read those references since most programming is supposed to suck if it's done by humans. It used to bother me when I was younger but I accept it as inevitable. Much like evolution itself producing tons of waste on its way to overall dominance of most of the search space. Once you get basic principles driving it, you must then work within that to squeeze as much of that good engineering as possible into those constraints. It's only way to have high impact or shift segments of the herd in better directions. Hell, it's a little like CLP for people & development processes. ;)

I'm including original essay, a great commentary tie-in in historical proof, and one by ex-high assurance guy Steve Lipner at Microsoft:

http://www.dreamsongs.com/RiseOfWorseIsBetter.html

http://yosefk.com/blog/what-worse-is-better-vs-the-right-thi...

https://blogs.microsoft.com/microsoftsecure/2007/08/23/the-e...

" The Prolog version is less than a page of code and half of that is direct translations of the puzzle hints to CLP constraints (the other half just sets up the variables and such.)"

It was beautifully concise compared to the others. Of course, they were trying to re-invent the parts like execution strategy that are hidden in Prolog. Your point seems to be that nobody taught them this or they didn't learn enough. That comes from combo of education system training people for workforce and popularity of imperative languages for FOSS. The environment is real problem. Changing that leads us right back to above essays. Two, good examples are Ocaml and Clojure. One gives them escapes back to imperative on their way to gradually learning functional. It's done better in uptake than most FP. The other made some changes to LISP while dropping it on top of one of evolutionary-strongest ecosystems. Got uptake no other LISP had up to that point. A subset of its users also started learning other LISP's.

"They're bad because they both would be better off implementing the resolution algorithm (i.e. mini-kanren) and then using that to solve the puzzle. It still would have been shorter and easier and faster."

" The machines are vast and fast enough now. Why is everybody..."

It would've been. Now we get to the point where you find that you may be caught in the same problem you're accusing them of. I can't remember Prolog or most programming now due to my head injury. Yet, I remember quite a bit about the market & what people did with it back when what you suggested was tried on a large scale by smart people. That was the AI boom where they coded in LISP, Prolog, Poplog, OP5, etc. I read all that, built expert systems with some of it, and tried to stretch it in new ways. I confirmed myself that it was very difficult to apply it to all kinds of problems where other models allow concise expression of problem or dramatically, higher efficiency. We collectively needed that development pace or efficiency to be competitive. The Japs even threw piles of money and brains at Prolog-specific hardware in their Fifth Generation project to bootstrap the goal you're talking about. All of that failed miserably. The AI Winter finished most of those companies off with a few pivoting and surviving.

So, in case you're wondering what we learned, it was that you don't want to write all your code in Prolog. Even those doing logical search in some cases. The default on bottom of the stack should not be Prolog. You want to use the most powerful language you can that supports DSL's & FFI's. You then embed things like Prolog in it to use when ideally suited for problem. Anything that's easier to handle a different way is done differently. LISP and REBOL were main proponents of this approach with Allegro CL still bragging about their Prolog implementation. "sklogic" added Standard ML to his LISP for coding safer, easier-to-analyze modules on top of DSL's for parsing & Prolog. Haskell has recently joined the fray where a number of DSL's are letting one mix benefits of Haskell and low-level languages like C. Galois Ivory language & Bluespec come to mind. If a tool such as SWI Prolog is used, the typical case should be prototyping & verifying Prolog source that's then embedded in a better tool like those. There's times like Zebra puzzle, NLP, etc where constaints allow it used standalone. Also, possibility of doing things in reverse extending Prolog with foreign primitives instead. More space to explore in R&D.

Point is that was the hard-learned lesson of decades of failures to do everything in Prolog. It just didn't work. It was ideal for some things but slow, hard-to-write, and hard-to-maintain for other things. Same was true for many models. Hence, a unified tool can express and integrate each of those models to let builder use best tool for each job. Alternatively, data formats, calling conventions, or protocols standardized to integrate separate programs using separate models. High-assurance recently did something similar for verification in DeepSpec program that led to CertiKOS OS. A bunch of DSL's are used. Prior efforts tried to build & verify it all in one tool like FOL or HOL but work was miserable.

" I've maintained for years that anyone who can solve a sudoku puzzle has the intelligence to learn to program."

I've never thought about it. Especially in light of Prolog. Very interesting. Now you got me wanting to drop Prolog on some Sudoku fan sites to see what happens. Have to have syntactic sugar, libraries for common things, and great tutorial so the start is painless. I'll hold off for now but keep it in mental peripheral if I see someone messing with sudoku.

"P.S. I'm still working on replying to your kind and excellent email."

Cool. :) Also reminds me I still need to take black and yellow highlighters to that book. Probably take it to work with me to mess with on lunch break.

Re: The Minimally-Nice Open Source Software Maintainer

#60
post #53

Earlier quoted context omitted.

That's quite anecdotal. It might be true and work for you. I'd then ask if it's the general rule that maintainers being helpful to people who have more to learn is causing lots of problems. I doubt it given the huge ecosystems with beneficial results that came from software catering to such people. Now, it might be quite different for those focusing on extra-high quality, reliability, or security. These seem to take…

First off, at least in my mind there's a difference between people asking good questions in order to learn, and people constantly making stupid proposals without taking time to learn enough context to understand why their proposals are bad. And, yes, of course it's anecdotal, and of course it's not universal. I don't believe my preferences for interaction should be universal. The software world is big enough that I c…

Good points.
Post reply on HN