Screw this dude. Screws us over with ridiculous projects and insane exams that are so hard to answer because he gets philosophical in his questions. He delves into a lot of redundant history and just generally goes on long tangents for extended periods of time, makes him seem like a good professor who wants to make students learn in depth but also makes me question what the point of some of his lectures is when they never make the exam. And after all this shithousery, he doesn't even curve our final grades. I ended up with a C despite being a consistently A/A- student because I did dogshit on his exams. He may have helped amplify my passion for CS, but I'm never taking another class with him again. My GPA and mental wellbeing took a strong hit with this dude.

TLDR - If you care a lot about cs at the risk of your own sanity/free time/grades, by all means ignore this review. If you just want to learn stuff and do exams and do a project, be very careful about this man and this class. It will screw you over if you're not at the very top of your game.

A lot of people really dislike CS 35L, since there's so much content and too little time to absorb it. Personally, CS 35L is my most favorite class at UCLA so far, since it taught topics like git/ssh/python/bash/make, which I LOVED learning about. HOWEVER, the class itself is still a pain in the ass. Assignments are often vague and time-consuming. As others have mentioned, this is TA-led, so your experience may vary. I was lucky to have an awesome TA that taught well.

Get ready to spend countless hours a week on these insane projects, especially the first two. Eggerts lectures are very interesting but often are not remotely useful to the homework until AFTER the assignments are due. Midterm and final are a guessing game of what might be on them, pray that you are able to take this class with Millstein instead.

I made the mistake of not githubing anything in this class. I know the material really well did remarkably well in the homework (as in lost points only because I submitted late), but you need only look at my grade to see how that turned out.

Here's a few tips for the class if you're looking for a good grade:
1) Don't try. Really. Just github all the projects. You'll need the high grades on homework since everyone else is githubbing too and they'll have perfect scores.
2) BS on the exam. You may know how to code well on all the languages and understand the concepts, it won't matter. You need to write as much as you can using words that pop up in lecture. Don't paraphrase.
3) If you're taking exams online, cheat as much as you can. They won't be able to tell as there is no way to tell.
Do yourself a favor, do what CS35L really tried hard to teach you to do: Copy, steal and lie.

If on the other hand you actually want to learn something in this crap class do all the projects yourself, read the textbook and try to understand by digging deeper into every concept.
You will learn a lot. I'm a better programmer because of this class. I'm a worse student however as my GPA says.
I am also a smarter human because of it too! I know now that you need to take advantage of everything you can regardless of whether it is fair or honest. I don't know if that was the lesson Professor Eggert was trying to give, or if he even cares enough to give any lesson.

I am bitter because of my results in this class, but at least I learned a lot.

GNU Emacs was the only thing of value that I learned in this class.

Whoa. So, before I 'defend' Emacs, I have to be very careful you know that this is not just a knee-jerk reaction and 'HeY yU iNsUlTeD mAh EmAcS', and that it is not unreasonable to think emacs is outdated. Emacs being outdated is most likely a myth, and that impression will most likely be spread by the fact that many don't use emacs, and never actually get to learn about what it is. It is often compared to text editors, namely Vim, and that is all the more reason it will just look like some old text editor, but it is not that at all. Emacs is not a text editor, emacs contains a text editor. Emacs is more like an example of ancient magic that people once had a hold on and was lost in modern times to some extent. The reason is its a full programming language interpreter with a text editor, at the bare minimum, built on top of it (and to the person who asked why 'nobody builds these things for IDE's', I don't know if that's true, but if there's any truth to it this may be partially why; not every IDE is a programming language, nor does every IDE allow full turing complete modding. Emacs is exceedingly suited for change, even ridiculous change). Better yet, the language it uses is possibly the most dynamic language in the world (lisp), one that allows you to touch and play with the code of the device while its live, and add on to it effortlessly. Hell, a language that allows you to modify the language itself. That is the pinnacle of modding and customization.

Anyways, because of this, its true power is not in its text editor -- many of us forgo the emacs text editing and just integrate vim's text editing into it. It does have a powerful text editor though, I still end up text editing Emacs style more often than Vim style, but anyways -- it is its power as a sort of operating system. You can always build new emacs tools, full programs if you will, and similarly we have continued to build emacs tools over time. You are not using 1970s emacs in 2019, it is still alive and well and extended. Emacs, as it looked when it first came out, was just a starting point, since its not like a normal program which is just a snapshot in time, but a fully organic starting point to grow anything.

It has some graphical limitations, not in functionality but in pure appearance, which can further give the appearance of being outdated, but none of the practical limitations.

Because of emacs' dynamic language nature, there is another secret gem that might be the true source of its power -- integration. Every tool you add to emacs can often be used in conjunction with every other tool in a very polymorphic way, which means adding features is less like "emacs + n + m" and more like "emacs * n * m"; every feature boosts every other feature. This has resulted in some tools that are true outliers, with true power that may not be emulated elsewhere, like org mode and magit (please look into magit if you haven't). Emacs can accommodate many workflows, and teach you some newer ones.

Anyways, as for actual emacs users, the number is not insignificant either. It doesn't have a majority usage, but I will usually see it with at least a 5% or 15% in different community interviews (example: https://insights.stackoverflow.com/survey/2016 ~5.2%). Looking at this survey, that puts it on the same usage (about) as PyCharm , VsCode, and PhpStorm, differing by about 2%, and about half the users of Atom, and it has several more users (in this survey sample) than a common editor like TextMate. It is still a common editor, just with an image of being old or unused or uncommon at time, if anything because its old.

Just as a reminder for the 400th time, one of the strangest things about emacs is its called a text editor, and maybe because in the beginning, that's all there were, and that's what its image became cemented as. Emacs is an IDE, a mini operating system, and much more, and never have I gotten as much features elsewhere as I have in emacs (although I do not claim they are not there), and never have I had the combined features you get from the unique combination and integration of all these features within it. From what I've seen, some emacs features are less refined than some other IDE counterparts, others are more refined. Emacs often (not always) requires more tinkering, an IDE less so. I have had times where I was able to use a huge mod pack for emacs 'out the box' like I would an IDE, and other times where it needed some adjusting. I will say its a bit like android vs ios; android if you want to tinker and freedom, ios if you want something that just works and don't want the freedom to break something. I will not be so bold as to say emacs is going to be the universal best for everything, just that its not outdated, and that it is going to have a very long shelf life. I do possible hope to one day, however, work on a new emacs with a makeover and an overhauled branding, as the latter I think is more what emacs is outdated on; its brand. I luv emacs. T-thanks for reading

Imagine showing up to the final having memorized all 1 billion emacs commands and still getting fisted harder than any other test. People literally showed up with 500 pages of printed notes for this final. All I could do was copy directly from my notes onto the final. I literally have no idea how I got an A in this class.

This was my second class with Prof. Eggert. I took 111 with him and had a similar experience. Prof. Eggert is a world class lecturer. The difficulty of the class comes from the coding assignments and the exams. The medians for the midterm was around 60% and the final was around 50%. This is higher than the usual medians. The issue most students have with the class is that the homeworks, as difficult as they are, do not prepare students for the exams. I think this is correct. Doing well on the homeworks does not imply good performance on the exams. This makes the approach to doing well on Eggert's classes less formulaic. To do well you have to understand the material in lectures and the textbook really well. Take detailed notes on lectures and read the textbook. The text book for this class is wordy and not as good as the 111 textbook, but it is still a good reference. The lectures go into greater depth than the textbook and are more important. Go to office hours of the professor to get help on concepts. Go to TA office hours to get help on assignments. I did not go to discussions because the TAs just spoon feed the homework code. A class this challenging is essential to a rigorous computer science education and for developing your intuitive ability. Eggert's goal, in his words, is to "test your intution". Therefore he makes his exams open ended (not really) and really pushes you to reason based on the information you learnt in class and from readings. Regurgitation of notes/readings will not help. All the people who complain aren't interested in maximizing their learning but are more focused on getting good grades. Eggert is incredibly knowledgeable and a treasure of the CS department. I wish we had more classes like this and less classes like that of Prof. Reinman's.
The few criticisms I have are that I thought that the typed reports (homeworks 3 and 6) were not necessary. I didn't learn that much from writing a 5 pg. reports. The TAs also don't provide detailed feedback on them.
The students who usually like Eggert are students who code a lot outside class and like coding.

This class was advertised as a replacement for the notorious 35L but we got egged just as hard. The tests? Terrible. The assignments? Worthless. The only thing good about this class was working with some really cool people on a big project. Even though the requirements were obscure and it took many many hours, it was fun to struggle together.

Everything you've heard about this class is true. The homeworks are awful and nearly impossible to do. The exams are the hardest things you've seen in your life and even Eggert talks about how this class has way more work than you should expect.

Now, even after saying all of this, I have learned so much from this one class and I think I would still take this again especially since it felt so rewarding after I was done.

Now, here is my unsolicited advice on how you can do well in this class. The breakdown was: 24% Homeworks (each 4%), 8% Project, 24% Midterm, 44% Final

The very first thing I recommend doing is starting the homeworks early. Literally the day or the day after they get out. If you're able to stay on top of them and finish them a few days before they're due, then you'll do great in this class. Don't be afraid to ask the TA's for help and make sure you understand the rationale and reasoning on why things are the way they are.

When you eventually fall behind, don't be afraid to just turn in an unfinished homework. It's honestly worse to take the late days because the work just starts pilling up so quickly and coding with deadlines is never a good idea. Given that, it is super important that you get the basic idea of what you would have needed to do (and why you need to do it like that) even if you don't get it working.

For the Project, spend as much time as you can on this. Test your code and make sure that your report is really good. There are a lot of edge cases that are not explained. Check Piazza, so you can keep up to date with the various edge cases people think of because you won't get all of them.

Now, for the Midterm/Final, to add on to what everyone else says, I would also recommend studying by trying to connect the various topics he talks about. For example, think about Garbage Collection methods and the issues that could arise if Java used Python's Garbage Collection. Overall, I studied by trying to connect the topics when I was writing my study guide(had to make 2) and then looking at a few practice exams to see if I knew how to approach it. I was able to do really well on the final and average on the midterm

Good luck to whoever read all of this, you're going to need it

This class is awful as everyone else says. Prepare yourself for an awful quarter with ridiculous projects and un-passable exams.

how could this guy keep lecturing in such a prestigious school?
it really hurts me that I'm paying about thousands of dollars just to take this kind of shitty, fucked up class.
getting rid of professors like this would be the first step to develop this school.
FUCK YOU EGGERT