Hacker Newsnew | past | comments | ask | show | jobs | submit | acscott314's commentslogin

Glad this is getting some attention

For central limit theorem to hold, the random variables must be (independently and identically dustributed) i.i.d. How do we know our samples are i.i.d.? We can only show if they are not

Add to that https://en.m.wikipedia.org/wiki/Why_Most_Published_Research_...

We've got to do better or science will stagnate



Was 14 and on a Friday boss gave me some money to go find a book on C. He would take care of the expense form. I read the book over the weekend, and he had me writing code on Monday. (The book had a diamond on the cover and didn't turn out to have the popularity of K&R). He told me to find example code and copy and paste it. I wrote a terminal emulator and a manufacturing quotation database (he provided me with greenleaf libraries). They both ran fast. All that accomplished and I didn't know pointers well enough to be able to teach them. This was in '86. I also had a full collection of Byte Magazine which was motivating. It is so less nerve-wracking writing code today, knowing what to do if there are bugs in the language or libraries.



Presumably, to consider productivity the purpose is to get the most bang (output) for your buck (input).

The cost, C, to create app, A, that generates income I, varies with the pool of talent that will actually do the work. Also, consider the entropy of the system A targets, the C to modify A, and the time value of I. Once complete, if your org can live that long, if your A is faster, higher quality, more pleasurable to use, more cachet, more media coverage, more support, more money, more envy than a set of competitors, then the language it's written in becomes the next hot thing--if the word gets out.

Anyway, the ability for a junior programmer to pick up the code, create valuable improvements and grow with the organization (a super-specialized language requiring continual self-training is counter to that quality), and be productive, is a very important factor sometimes. So output can include very many, different things.

Function points may correlate to lines of code. If that's the case, then also consider the lines of code does not necessarily correlate with output. For instance, having to guess the correct search term to find the library you are needing to write that one line also takes time. Making sure the version of the library you are using plays nice with other libraries, the language syntax targets the version of the compiler, interpreter, hardware, architecture, platform, kernel, and standards also impacts output.

It is an interesting attempt to measure productivity with function point analysis. But, and you knew that was coming, there are so many more factors involved before you it is justifiably reasonable to draw a conclusion on productivity of a language.


Why is this article on HN? Come on. Select * is just a construct. When is it bad? That would be a better discussion. In any case the article demonstrates a lack of fundamental understanding of relation database technologies such as a clustered index...hm wait. I'm taking the bait. Read a good book on relational databases. SQL for Smarties will get you started.

Is select count(1) from mytable faster than select count(*) from mytable?


Desktop client disk space is large enough to have a VM for many sites. In the future, if it increases enough to have a VM for every web application _and_ work offline you have the selling point that the app can work during infrastructure failures. People will buy that. Sandbox the networking so it only can call your site and you have solved some of the security problems mentioned. Trouble is, large amount $$$ is behind tablets and their ilk. So you have to work on this for another 10 years when desktops come back. That will happen when Moore's law returns into existence. Light-based computing or analog-fusion-digital computing comes on the scene. What you have is a homomorphism to just a desktop application. The browser has grown to be a glorified dumb terminal that can display rich interfaces, and so the lines are blurred enough to confuse anyone trying to handle the client/server distinction. Best bet is to turn it into a platform that enterprises can use to solve their existing problems. Niche play. Great work, BTW.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: