Hacker Newsnew | past | comments | ask | show | jobs | submit | more thealig's favoriteslogin

Very insightful paper, thanks for sharing.

Firstly, I'm surprised that having no garbage collection did not make to the list of the seven deadly sins.

Secondly, someone here also mentioned about the very useful Turbo Pascal IDE and having an excellent IDE can really help in the visual learning approach that's required by all learners [1]. If any programming languages has the intuitive capability for real-time visual interactions as described by Brett Victor it will be great [2].

Thirdly, the paper failed to mention that beginner friendly programming language has a very high chance to be adopted by the industry and becoming extremely popular. This is self evident by the recent exponential popularity of Python. When the paper was written back in 1996, Python was just another scripting programming language with "Jack of all trades, master at none" language. At the time it's playing second fiddle to popular programming languages including Perl, PHP and TCL! The same can be said to D language now but as they've always said, time will certainly tell.

Personally I think D language did not tick most of the seven dealy sins boxes and have made the most of the seven significant steps towards more teachable language mentioned in the paper. It has the most Pythonic feel to it compared to other compiled languages. It also the has default garbage collection that will make it an excellent introduction for programming. Of course you can exercise bit manipulation like a madman with D (also cautioned in the paper) but that's only when you really want to after you've considerably comfortable with the language [3]. The only crucial thing that's currently missing is an IDE that is intuitive and beginner friendly.

[1] The Biggest Myth In Education:

https://www.youtube.com/watch?v=rhgwIhB58PA

[2] Bret Victor - Inventing on Principle:

https://www.youtube.com/watch?v=PGDrIy1G1gU

[3] Bit packing like a madman (DConf 2016):

https://news.ycombinator.com/item?id=28522040


My co-authors and I wrote "Taming Text" (https://www.manning.com/books/taming-text) specifically for programmers (there is little math, mostly code) interested in getting started in NLP. The examples are a bit dated at this point (2013 publication date), but still applicable for someone getting started. Covers getting started, feature extraction and preprocessing, search, clustering, classification, string heuristics, Named Entity Recognition and finishes off w/ a simple Question Answering system. Examples are in Java. It is not an academic treatise.

> There are lots of standard functions still missing, but rather than implement them as built-ins, they can be implemented from the primitives already available.

I'd be interested in reading more about this. For example, how was that set of primitives chosen? How does the author know that the set of primitives is sufficient?

A couple relevant (and interesting) links:

What is the "minimal" set of primitives needed for a Lisp interpreter? https://www.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/part1/f...

What is the smallest definition of Lisp? https://www.reddit.com/r/lisp/comments/aklz0x/what_is_the_sm...



For another gentle introduction to GPU architecture, I like "The Graphics Codex", specifically the chapter on Parallel Architectures: https://graphicscodex.courses.nvidia.com/app.html?page=_rn_p...

Awhile ago I wrote a Python library called LiveStats[1] that computed any percentile for any amount of data using a fixed amount of memory per percentile. It uses an algorithm I found in an old paper[2] called P^2. It uses a polynomial to find good approximations.

The reason I made this was an old Amazon interview question. The question was basically, "Find the median of a huge data set without sorting it," and the "correct" answer was to have a fixed size sorted buffer and randomly evict items from it and then use the median of the buffer. However, a candidate I was interviewing had a really brilliant insight: if we estimate the median and move it a small amount for each new data point, it would be pretty close. I ended up doing some research on this and found P^2, which is a more sophisticated version of that insight.

[1]: https://github.com/cxxr/LiveStats

[2]: https://www.cs.wustl.edu/~jain/papers/ftp/psqr.pdf


Apart from Blender, what tools/libraries should I learn to use to do this?

I'm 48 and have gone through this process countless times, it feels like familiar rote:

1. Explore the subject almost randomly. Neither depth-first nor breadth-first; just follow threads that seem most useful or most interesting. Books, articles, videos, classes, whatever - it doesn't matter as long as you don't get bored. Dabble in all of them. If there are any practical skills involved (motion, writing code, etc) start doing those immediately.

2. At some point you get the ah-hah! moment. It is like the fog lifts and you can suddenly see the landscape. You don't know everything but now it seems like further knowledge is just a process of filling holes. You wield your knowledge to accomplish what you need by filling specific holes on-demand. Everything fits together like jigsaw puzzle pieces.

The time between #1 and #2 can be short or long depending on the complexity of the subject. But the experience of #2 is a massive dopamine rush. The main thing you need is patience; don't get frustrated and give up, you know that if you just keep poking around, eventually that dopamine rush will come.


I am Ron Garret (f.k.a. Erann Gat), the author of the followup study mentioned in TFA. I am, frankly, amazed that this work is getting the amount of attention that it is over 20 years after it was published. I have a couple of comments about this latest critique.

> Given that the participants were recruited from internet groups, I doubt that the subjects were monitored in place, which makes me think that the Development time data collected should be taken with a giant grain of salt.

> Based on a small study like Garret’s, I find that the premise that Lisp is so great is unwarranted.

That's a fair criticism. In my defense I will say that I didn't actually claim that Lisp is great, only that it seems plausible that it might offer the development speed and runtime safety advantages of Java and the execution speed of C, and so it is worth paying some attention to it, and maybe doing further studies. I certainly believed (and continue to believe) that Lisp is great, but I certainly concede that my data didn't (and doesn't) prove it. Renato seems to agree:

> However, the data does suggest that Lisp is about as productive as the scripting languages of the day and has a speed comparable to C and C++, which is indeed a remarkable achievement.

FWIW, my study was a throwaway side-project conducted on the spur of the moment in my spare time. It was intended more to get people's attention and make the case that Lisp ought to be considered alongside Java as an alternative to C than to be a rigorous scientific case for Lisp's superiority over Java. At the time, Lisp was quite a bit more mature than Java, and indeed one could have argued (and indeed could argue today) that Java was an inferior re-invention of many of the ideas that Lisp had pioneered, with automatic memory management being at the top of that list. I was frustrated that Java was getting all the attention because it was the shiny new thing and Lisp was being ignored because at the time Java actually sucked pretty badly. (IMHO it sucks pretty badly today too, but that is now a much harder case to make.)

In any case, what astonishes me most is that AFAICT no one has ever done a follow-up to either of these studies that was better designed and used more rigorous methods. Instead, people just seem to keep citing these papers again and again as if squeezing these turnips harder might yield something worthwhile now that could not be extracted from them when they were first published.

This is a very fertile field for further research. Someone should cultivate it.


Going along with this: What are the latest and greatest open source speech-to-text models and/or tools out there?

Would love to hear from experienced practitioners and a bit of detail on the experience.

Thanks HN community!


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

Search: