Hacker News Reader

Comment by asutekku | Hacker News Reader

Just for the future reference in terms of conducting surveys and helping aggregate the results, please consider not using open fields on topics that would benefit on predefined sets and one open field called "Other".

Now there are lists with almost 400 answers with most of the answers being practically the same ("personal stuff", "personal projects", "personal things"...). It does not make it easy to digest the information.

View on HN

I've seen surveys that have open fields like that before but they usual use some keyword analysis to distil the results down (though I've always been sceptical how well their NLPs interpret messages like "I always use for personal projects" and "I never use for personal projects" as polar opposites despite the similar wording).

Anyhow, in this instance you're right that there isn't even a need for open fields, there's enough examples online already of IT being separated into distinct sectors for field selection on forms.

But what really grated me the most about the results was that there didn't even seem to be any deduping of the results (or if there was, it was case sensitive):

    ("Everything" "everything")
    ("Personal" "projects")
    ("web development" "Web development")

And there was even an instance where prototyping appeared twice because one instance had \s afterwards!

The author of the survey could also have gone through and compiled the results to be more easy to read.

Quite fitting for a LISP survey.

In other words, instead of doing it the standard, commonly-accepted way, the author did it his own way, and it ended up being worse.

The Lisp Curse.

(for the lucky 10,000: http://www.winestockwebdesign.com/Essays/Lisp_Curse.html)

That was written by someone with (at the time) some experience in web development and zero in Lisp.

The request "Update on October 6, 2017. N.B.: Please stop submitting this to Hacker News!" should be interpreted in its strongest form: i.e. including comments.

The commentary on adding OO to Lisp, I feel, is still very illuminating. As for "not reposting to HN", I take that as "don't clutter up the front page with something that's been posted multiple times already and has been discussed to death." Posting it in a comment for those that haven't seen it is nowhere near comparable.

The commentary on adding OO to Lisp is garbage.

> "Making Scheme object-oriented is a sophomore homework assignment."

Demonstrating basic OOP in C is likewise a suitable homework assignment.

http://rosettacode.org/wiki/Inheritance/Single/C

Making a viable object-oriented programming system for others to use is not a trivial task in any language.

No object system for Scheme that people actually use had been written by a sophomore as homework and gone into production in that state. (Linux started by a school kid tinkering with kernel programming too; but it would be a strawman to say that a bright undergrad can make a serious Unix clone in a few weeks that Amazon can put into the cloud and sell services on.)

The Common Lisp object system took many people years of work, and integrates deeply into the language, such that every object type has a class and can participate meaningfully in the object system without being wrapped in a class.

> Due to the difficulty of making C object oriented, only two serious attempts at the problem have made any traction: C++ and Objective-C.

Those are examples of having enough traction to actually get people to switch from C to a new language.

Ad hoc object systems have been implemented in C programs umpteen times, and a number of such things are available, or have been historically available, as formal libraries for use in C programs.

These all have "traction" in their "respective" projects and ecosystems; there is a lot of OOP action within C.

> Ad hoc object systems have been implemented in C programs umpteen times, and a number of such things are available, or have been historically available, as formal libraries for use in C programs.

Including CLOS-like OO extensions for C.

Like Dynace:

https://github.com/blakemcbride/Dynace

This is good feedback, I will certainly consider that for the future.

Absolutely. Most of the questions effectively cannot be evaluated.

They can be evaluated, it's just going to be difficult to do it as a quantitative analysis.

Which is actually kind of fine with me. After a long long period of people only being interested in asking questions when the answer can be graphed, it's nice to see some individuals' actual feelings and opinions showing through in the results. For example, "all tasks that do not require close OS functionality" was a gem of a response that you'd never see in a survey that consisted solely of checkboxes and radio buttons.

Reply on news.ycombinator.com