Is that 50 lines of code, or 50 lines of using a library that's thousands of lines of code?
It makes sense to talk about lines of code when thinking about engineering hour efficiency. It costs the same amount for a programmer to write one line of C as one line of Assembly, and the rate of bugs tracks lines of code as well. The underlying libraries and abstractions should be considered if you're thinking about computing efficiency.
The time it takes to learn and master the language aren't irrelevant either.
If anyone wants to jump into this, Josh Tenenbaum and Noah Goodman put together this amazing interactive book for learning probabilistic programming with Church: https://probmods.org/
Great project but very weird choice of language. How probable is it (pun intended) that the person coming to learn about probabilistic programming would already know functional programming?
I actually considered that book as good as any ressource for functional programming introduction.
Is that 50 lines of code, or 50 lines of using a library that's thousands of lines of code?
What do we say about languages built on C? Is it 100 lines of code but there are hundreds of thousands of lines of code for that higher level language you just coded? I don't think libraries count in terms of code. We all use code to program. Standing on the shoulder that preceded us. Using a library and a function should just count for the most part.
I think stevenspasbo did not mean to criticize the progress in this area, but rather just point out the misleading title of the article. Unless you program everything in pure ASM, Bios and up, you always stand on the shoulders of others, that's how since works. But the title of the article, "Probabilistic programming does in 50 lines of code what used to take thousands," makes it sound as if there was a solution to these complex problems that could be expressed in 50 lines of code all along, and only now did we figure it out. The truth is, people have written thousands of lines of code, and put them into libraries, and now those tools can be used and leveraged to express complex solutions more easily.
Wouldn't you just take the length of the vector with sqrt(4+9+16) and divide each component by it? Or is this a different kind of 'vector' than graphics people are familiar with?
But Obviously. The same chap can invoke the SparseVector and DenseVector Java APIs from Spark, but doesn't know what a simple unit vector is or how to compute one. I think we are entering into a bleak era where there are umpteen built-in ML APIs for everything under the sun but the engineers who use them have no idea what these things really are - they just invoke the constructor and write some code and think they ar…
Seems hard to believe that an "engineer" with a degree in engineering or CS wouldn't know what is a unit vector.
Great project but very weird choice of language. How probable is it (pun intended) that the person coming to learn about probabilistic programming would already know functional programming?
Isn't functional programming a standard part of any computer science curriculum? Why would you expect programmers not to know it?
Great project but very weird choice of language. How probable is it (pun intended) that the person coming to learn about probabilistic programming would already know functional programming?
Isn't functional programming a standard part of any computer science curriculum? Why would you expect programmers not to know it?
Great project but very weird choice of language. How probable is it (pun intended) that the person coming to learn about probabilistic programming would already know functional programming?
Isn't functional programming a standard part of any computer science curriculum? Why would you expect programmers not to know it?
I was very surprised to learn from two Stanford CS alums that functional programming was not a requirement in that program.
But Obviously. The same chap can invoke the SparseVector and DenseVector Java APIs from Spark, but doesn't know what a simple unit vector is or how to compute one. I think we are entering into a bleak era where there are umpteen built-in ML APIs for everything under the sun but the engineers who use them have no idea what these things really are - they just invoke the constructor and write some code and think they ar…
Seems hard to believe that an "engineer" with a degree in engineering or CS wouldn't know what is a unit vector.
Why? There are plenty of directions you can take through a CS degree that will never have you dealing with vectors at all. And subsequently there are plenty of CS heavy careers where you will never deal with it.
What little I remember about vectors is from my high school maths classes, and in my 20 years of doing software engineering it's come up exactly once (for a GIS related project).
Great project but very weird choice of language. How probable is it (pun intended) that the person coming to learn about probabilistic programming would already know functional programming?
Isn't functional programming a standard part of any computer science curriculum? Why would you expect programmers not to know it?
Even the places where it is a part of the curriculum, it is often such a small part that unless people specifically take courses related to functional programming you can't expect them to be able to actually use it. Or remember much of it for that matter.
Heck, I spent months on a binge reading functional programming research papers, and it still doesn't mean I know any functional languages other than very superficially.