4 ms·

There are courses definitely worth trying: ML is the general introductory course. PGM is more about applied knowledge. NN is a specialized and very good

There are courses definitely worth trying: ML is the general introductory course. PGM is more about applied knowledge. NN is a specialized and very good one. Scala is just a buzzword. Lisp is a language for AI for many reasons - it has almost no clutter, so you can read it. There is also Berkeley CS188.1 on edX, which covers search. Of course, just courses are not enough. You need textbooks, AIMA, PAIP and PGM are highly recommended. But most importantly you need practice. One cannot learn how to swim, ride a bicycle or wrestling just by reading books and watching movies. Very few regions of your brain learn something just by watching and listening. Those which are active when you actually do something must be trained by doing. It is how you will form your own intuitions, timing, etc. Non-verbal parts of the brain are doing the most of the job. Neural networks need to be trained on real data to learn its behavior.) This simple idea is a cornerstone of MIT approach in teaching CS. They do lots of projects and labs, working in groups. This is real training. Recent version of 6.01 is a good example. So, start your own project or join some Open Source. Then you will get real practice, training and feedback from other people. It is not meeting that matters, it is practice.

michaelochurch 14y ago
I agree with most of what you're saying, but not this: Scala is just a buzzword. Disagree. There's a strong case for static typing. I am not saying that it is "right" or "wrong", but this static/dynamic trade-off is not simple and has no all-purpose answer. Also, you will never convince most engineering managers to let you write a production system in Common Lisp. They may be wrong in their prejudice, but they're focused on risk-reduction and would prefer all production software to be written in Java. Scala has a fighting chance of getting into the "for production" language space. In 15 years, most of the good Java engineers are going to have moved to Scala and prefer it. Out of curiosity, have you tried Clojure? It's pretty neat. I actually like it better than I like Common Lisp.
- dschiptsov 14y ago
  they're focused on risk-reduction and would prefer all production software to be written in Java. - this is cancer, so to speak.) I know only one way to reduce a risk of running a software - choice an appropriate hardware, and run as less software as possible. You must know your hardware and your software. That means it must be compact, readable and easily modifiable, so that you can quickly adapt and fix it, on the go. So, I would choose a well-defined, mostly-functional, small, simple language, with decent compiler directly to native machine code and very thin FFI, to use specialized OS services. It could be a solution from http://scheme.com http://scheme.com or Gambit-C, not anything that begins with J. So, in my opinion, a native compiler for, say, Arc to x86_64 (written in Lisp) with UNIX integration (NO Windows support) would be a better solution. Unfortunately, it doesn't exist yet.) It seems like Go is taking the same approach - they have very thin layer of abstraction on top of an OS (post of Plan9 core libs) they have native compilers, and comprehensible runtime. So, this is real, available better solution. There is Erlang - almost the same underlying principles, but complicated with a VM. In order to reduce risks you must have deep understanding of what you are running.
  - dysoco 14y ago
    I'm loving Go, it doesn't have a lot of libraries designed for Machine Learning, but it's easy to write wrappers and we have one for Bayesian operations: https://github.com/jbrukh/bayesian https://github.com/jbrukh/bayesian I'm investing my time in learning this language: I'm sure it will be more widely used in the following years.

michaelochurch 14y ago

I agree with most of what you're saying, but not this: Scala is just a buzzword. Disagree. There's a strong case for static typing. I am not saying that it is "right" or "wrong", but this static/dynamic trade-off is not simple and has no all-purpose answer. Also, you will never convince most engineering managers to let you write a production system in Common Lisp. They may be wrong in their prejudice, but they're focused on risk-reduction and would prefer all production software to be written in Java. Scala has a fighting chance of getting into the "for production" language space. In 15 years, most of the good Java engineers are going to have moved to Scala and prefer it. Out of curiosity, have you tried Clojure? It's pretty neat. I actually like it better than I like Common Lisp.

dschiptsov 14y ago
they're focused on risk-reduction and would prefer all production software to be written in Java. - this is cancer, so to speak.) I know only one way to reduce a risk of running a software - choice an appropriate hardware, and run as less software as possible. You must know your hardware and your software. That means it must be compact, readable and easily modifiable, so that you can quickly adapt and fix it, on the go. So, I would choose a well-defined, mostly-functional, small, simple language, with decent compiler directly to native machine code and very thin FFI, to use specialized OS services. It could be a solution from http://scheme.com http://scheme.com or Gambit-C, not anything that begins with J. So, in my opinion, a native compiler for, say, Arc to x86_64 (written in Lisp) with UNIX integration (NO Windows support) would be a better solution. Unfortunately, it doesn't exist yet.) It seems like Go is taking the same approach - they have very thin layer of abstraction on top of an OS (post of Plan9 core libs) they have native compilers, and comprehensible runtime. So, this is real, available better solution. There is Erlang - almost the same underlying principles, but complicated with a VM. In order to reduce risks you must have deep understanding of what you are running.
- dysoco 14y ago
  I'm loving Go, it doesn't have a lot of libraries designed for Machine Learning, but it's easy to write wrappers and we have one for Bayesian operations: https://github.com/jbrukh/bayesian https://github.com/jbrukh/bayesian I'm investing my time in learning this language: I'm sure it will be more widely used in the following years.