It is essential to be able to efficiently use a text editor, and doing
all your writing / coding / text processing in one of the common editors
available on all Unix systems is good practice. vi(1)/vim(1) and emacs(1)
are popular choices.
My college instructor encouraged the use of emacs in particular. I eventually migrated to vim but appreciated the instructor’s core message that text editor + CLI feels less magical than a full fledged IDE.
After 10 years of writing software for a living I still don't get this. Why vim/emacs and not Intellij (for instance?). What do you mean magical - I want a powerful tool to help me edit code...
I'm assuming the rationale is that for someone who's doing complex system-level stuff on unix/linux they should be able to change things deep in the weeds instead of pulling the entire code out to IntelliJ or an IDE.
I honestly mean this with no disrespect but having written code exclusively in vim in the terminal for several years and the same in IntelliJ, I am confident that either:
- you don't have to write Java full time, and/or
- you don't have to work in a large Java code base, and/or
- you haven't been exposed to IntelliJ's features and how they can save you time
I love vim, I really do, but IntelliJ is a Java-specific IDE and there is absolutely no way that vim or emacs or vscode can compete on features. You can refactor code in a split second in ways that are just not possible in vim/emacs. IntelliJ has an understand of the structure of your Java code that vim simply doesn't have and will never catch up to having as its a general purpose tool and IntelliJ is a specific tool. Its vim mode is also pretty good. The only downside of Jetbrains IDEs is that they can be slow when indexing large projects and they can be slow in general. But I would still 10 times out of 10 choose to make a commit in IntelliJ over vim for a Java project that is non-trivial.
If you write Java I would (as strongly as possible) recommend giving IntelliJ another go and looking into its refactoring and other features.
This thread is about a course on Advanced Programming in the Unix Environment. After looking at the content of the course, I'd argue that there's an implied "Systems" between "Advanced" and "Programming". (Indeed, this course is taught using the famous book whose title it borrows, and is heavily C oriented.)
Java is neither common nor especially well suited for the topic of this course.
So while I share your opinion on IntelliJ as a Java IDE, I would not recommend it for UNIX systems programming. And even the IntelliJ-derived Clion, which is (IMO) decent for that, leaves something to be desired when it comes to learning the topic.
The necessity of intellij just shows how much Javas type system is abused. I don’t know what it is about java but you see the craziest types in codebases: IAbstractBeanFactoryResolverInjector<IDisplayableAppletResolverInjector>
Is that the type system's fault or the whole Spring/dependency injection fault? You're using a typed language and making it behave in dynamic ways when using Spring (at least that's the impression I had when I looked at Spring).
Tbf I’m a heavy vim user but I’d still 100% use IntelliJ to write Java. It’s different to most other languages in its verbosity, and the fact that (imo) it doesn’t slot nicely into Unix conventions in general.
Sun never really integrated Java into its UNIX environment very well, IMO. My memory of that time is spotty but I don’t recall any of their UNIX tools actually being written in it. (Likely because the startup time is awful, which is bad news for any CLI programs which need to execute and finish quickly.) The Java way of doing things and the UNIX way of doing things are worlds apart. UNIX prefers small executables that do simple tasks, mostly with text, tied together with scripts, where Java (at least at the time) preferred pure-Java libraries assembled into larger applications with graphical interfaces. Sun never seemed to square that circle, and Java felt like a second-class citizen on Solaris.
I mean sure, IDE’s are an obvious choice for Java. But the rest of the usages of Java in SunOS I would consider token at best.
One thing I never understood was why I couldn’t just write some Java, compile it [0], and hand the result to someone else on a Solaris system, and have them run it.
Sure, they may know how to run “java -jar myapp.jar”, but why was that necessary? Why couldn’t it be a standalone executable, that didn’t require the end user to know in advance that it was written in Java and to invoke it accordingly?
Every single bit of Java software I ever used on Solaris always had some sort of shell script wrapping it. I never understood why the operating system couldn’t just natively execute Java code… they literally wrote the entire operating system, language, compiler, toolchain, etc, and the end result wasn’t usable without arcane wrapper scripts and JAVA_HOME conventions and so forth. Windows managed to make it work with .NET (they were just .exe’s like everything else), I always thought like Sun could have done so much better with the end-user experience with running Java software.
[0] for any loose, reasonable definition of “compile”. I’m not saying it can’t be byte code, that’s fine… I just don’t want to have to care. I should be able to copy it to /usr/bin and just run it without having to invoke “java -jar”, or use some weird self-extracting shell script trick. And I shouldn’t have to care about whether the person I’m distributing it to has Java installed, because it should have always been the case that a given SunOS machine should have a working Java install… the same company made the OS and the language for chrissakes, every SunOS installation should have had it as a mandatory component.
One might hope, but they didn't. How do you tell in Java if stderr is a TTY, and if so, what its width is? How do you do an NSS passwd lookup (as in getpwnam("pjmlp") in C etc.)?
(To be fair, these could be defended, very slightly, on the grounds that Java is a cross-platform language, even though other cross-platform languages have better answers. But then I'd raise the point about Java corrupting RLIMIT_FILES for processes it starts....)
The same way you can tell in Limbo, and its authors did know one or two things about UNIX and its evolution, although this might be considered moving goalposts. :)
Yeah, I'm torn on this. I wrote C in emacs for 20 years, and still do. But when I write anything else, particularly javascript, java and rust, give me intellij ide's...
Perhaps "magical" = increased complexity, like you can't just build a standalone source file. You have to setup a project first, configure the required build XML, add your code files to that project, etc etc then finally compile it.
with editors like vim/emacs, it's much simpler, like typing `vim test.c` and `gcc test.c -o test`. OK it's simpler, assuming you already have the toolchain installed properly. In general it's true, a few lines of apt-get/homebrew/etc get the job done.
BTW, I have nothing against IDE. As a Android developer, I won't ditch Android Studio for any editor. But for quickly navigating or building non Java codes, I'm happy with vim + Makefile/scons/etc. Or VSCode, if I'm not in the mood of running full featured IDE.
For coding in your normal day to day? Sure use intellij. For trying to debug some deep level production only issue where every second of downtime means big money lost? You'll want to know vim/emacs..
Edit: I'll also add that once you learn vim or emacs you'll be far more efficient manipulating text. Sure you could add the bindings to intellij, but I think that's admitting the point is valid. At a point it becomes like a real time meta language where you edit lines the way you would algorithmically.
Yeah I can see that's possible sure. Though if I have access to the code I just use Github but sometimes I guess that's not possible.
Still quite rare though no?
In some places it's rare, in some places it's a daily occurrence, and sure you should work towards stability, but the reality is you have to fix this thing now with what you have. There's also the fact that even if it's rare I still have to know it. And if you don't use it often you will forget it. And then why learn two tools if I can do everything with 1? With intellij I can only do day to day, with vim I can do mission critical and day to day. I'd also argue that a seasoned vim user can get things done incredibly faster than a seasoned intellij user.
Experienced emacs users will beg to differ. It is as capable and arguably, more easily extensible. I must admit, it is not for everyone. As your anecdotal 10 years experience, I have the opposite opinion but I think it is fair to say that both, Graphical IDEs and emacs/vim, have their merits. Having transitioned from Graphical IDEs -> vim + plugins -> emacs + evil + configs + org-mode. I will never go back to my old self, I've never been as productive and free.
Same trajectory here. I started with vi(m), used a handful of IDEs along the way, but vi(m) was (is*, if I'm in my terminal and just need to edit a config file or look at some data file, and sometimes even just for reading source, I default to using neovim) a mainstay, and I also eventually landed on Emacs with evil-mode. I still use an IDE frequently for graphical debugging. I find it's the best way to approach thorny problems, but I jump in and out of the IDE quickly. I don't hang around in it and write code, almost as a rule.
I vaguely remember hearing something like that when I just started uni and they had us all working on Emacs. I can attest it added zero value to me...but that's just me.
Quite simply, I may have to login into a server on a high pressure time sensitive environment, think downtime. I want to maintain my vim skills at a level that allow me to focus on the issue. It's also why I use bash and GNU coreutils on my MacBook Pro.
Sooner or later, in many lines of programming, you are going to find yourself remoted in to a server somewhere that only has the basic tools. That’s probably not the best time to try to learn an editor.
Because it teaches you that compile and run aren’t just buttons on a window, it’s taking one or more files (streams of text == data) and translating them into other files.
Same, the professor used Emacs in only programming class I took in college. Seeing what he could do with Emacs left as much of an impression on me as the rest of the material, and I've never considered another editor seriously since.
I'll just go ahead and shill acme: If you want to learn the Unix programming environment, vi and emacs are good in that they will work mostly as expected on any OS, but that's because they don't assume that you will use any user level applications. On acme, it's assumed you that have a shell, plumber and a whole load of commands and scripts ready to help out (as well as a mouse).
In the process of learning Unix you learn acme for free and vice versa.
I don’t know man… Acme requires a GUI (and a mouse), has been imported from Plan 9 (Unix does not have a notion of a “plumber”), and its UI is pretty much a copy of Oberon’s. The way it look to me, this is as far removed from whatever Unix is all about as it gets…
> learn to develop complex system-level software in the C programming language while gaining an intimate understanding of the Unix operating system
I would have loved to take a course like this in college, though I didn't have the chance. I do think [Rust In Action](https://www.manning.com/books/rust-in-action) is a good introduction to some of the same concepts, if anyone is, like me, yearning for grad school while having to hold down a job. While it doesn't use C, I think it teaches systems programming in a way that's easily applicable to any language.
The lecture videos and syllabi are up on the gatech websites for each class, but the project materials and such are not publicly available as far as I'm aware.
I'm not sure what you mean. There are many systems languages out there these days: C/C++, Rust, Zig, and even Go and Nim for things like file systems and networking!
> Students are expected to have a good working knowledge of the C programming language, have written non-trivial programs before, and to be able to competently use a Unix system with a command-line shell interface. All coursework will be done exclusively on a Unix system from the command-line. This is not an introduction to using Unix!
My son just finished an undergrad CS degree at a major university and I don’t think he’d meet this pre req.
I’m not sure - I took an operating systems course in C that used command line only for submissions, and of course if you didn’t run a *nix locally you had to SSH in and work in a terminal environment for the entire course. This was three years ago. You could nitpick about what “non-trivial” means, but I’d say most CS degrees require some non-trivial work(to them).
Just because they have experience in C and (hopefully) some non trivial work over the course of the entire degree doesn’t mean they have non trivial experience in C.
I’d love to hear what the author considers nontrivial but I’m going to guess it has something to do with pointers, and familiarity more generally with the memory model of C.
Yeah I guess it’s the non-trivial bit that needs clarification. My son shelled into nix systems and wrote some c++ code that made system calls. It’s just the way the prereq was written leads me to believe a good portion of his time in this class would be spent on learning things ancillary to the main content.
Honing in on what is meant by "non-trivial" is a good point, because it will really mean different things when talking about different audiences.
I took a few undergrad CS courses during some downtime recently and found them blindingly, disappointingly easy to the point where I found myself fading the (prestigious) school that created the material. They felt completely trivial, as did the assignments.
On the other hand, I'd be willing to entertain the argument that I've not yet written a non-trivial program in my ~10 years working.
I used to work out of a space provided to my employer by a university, as part of their startup accelerator program
It was on-campus and there were students also in that space, so during lunch and breaks I got to know many of them
In my experience, students about to graduate from the CS program had near-zero tangible skills and lacked the ability to build basic applications, in any language.
This was in the USA, FWIW. I think our CS programs are pretty trash at most universities.
One of my current coworkers applied after graduating and failed the interview and was only able to pass after paying thousands to attend a coding bootcamp.
The fact is that most CS graduates go and work in industry when they're finished. Having some basic knowledge on how to deliver and architect software projects would come in really handy considering that's what they'll be doing as they've graduated.
Yeah, but that's the shit I can teach them easily on the job. I'd rather their degree teach them the answers to the "why" kinds of questions. It's more onerous for me to schedule someone to shadow them and answer those.
That's kind of the point of splitting CS degrees into general undergraduate basis and specialized graduate level. In undergraduate you have to learn the basics of everything and can start to specialize on projects or bachelor's thesis if your uni has one, then you finish your specialization during graduate studies. You can be a very good software developer without ever touching a command-line interface or having a working knowledge of C these days. On the other hand if you want to become a C/Unix developer, there are enough courses and projects available for you to learn.
Also I'm fairly sure you can start a course like this even without matching the prereqs, it's just gonna be a bit harder, but university is all about challenging yourself...
Many peers at my CS program (I graduated a few years ago) also wouldn't meet these prereqs.
1. Exclusive use of Windows. You couldn't submit binaries unless it was compiled with msvc.
2. Junior year was when we were first taught the shell. This was a major challenge for many as they didn't understand commands like `cd` or `dir`.
3. C was never taught, even in our OS course, it was all C++.
4. When working on my senior project with my team, one of my teammates asked if his code needed to compile (the IDE had riddled his code with red underlines for the many, many syntax errors)
5. Bonus: Git was never taught. When I suggested to a teammate that we collaborate on GitHub he instead emailed me his code.
So? This is a specific course with specific requirements. Many unis today don't teach C nor require students to be familiar with Unix, but if you think about writing server-side software it's an excellent introductory course.
There's some debate about the role of practical instruction at engineering colleges. One one hand, you have people who say "no. we shouldn't be teaching basic skills like C programming." Their point is a university level education is supposed to teach people how to think about the concept of computability and algorithm analysis. They will frequently say things like "we are not a trade school!" The other side of this debate are people who are like "Meh. It's embarrassing our grads can't write a C program." So they teach them Python.
Either way, the only way you're going to graduate knowing C programming is to realize it's something you want to do and spend a bit of your own time learning it.
And then they completely fail to teach concepts usable as a gigging coder.
I think if you ask the academy "what are you teaching young software engineering students?" the response would be something along the line of "We're teaching them knowledge and skills that will be useful for being a grad student."
It would be cool if there was an organized course teaching kids the basics of version control, what continuous integration and continuous deployment are, what agile methodologies are supposed to do (as opposed to "agile is whatever is in the JIRA manual"), the basics of logic programming -- you'll never use prolog but you'll be rewriting it in C++ or C# a couple of times, the basics of functional programming -- you'll never use lisp, but you'll be pretending function pointers are the same thing when you're writing that big C++ program, software project estimation, how to invert a binary tree -- you'll need to know this for a google interview and how to actually design data structures.
Systems is legitimate academic CS. It is different from modern business or web application development in important ways, but it is at least hands-on-keyboard edit-compile-test cycle work, not math. You should should understand how an operating system, network stack, database, etc. works by having implemented significant parts of them in homework. That is part of the virtue of having a CS education, as opposed to a trade education. A CS education with only math is at best incomplete.
And to bang on my usual academic CS bugbear on HN: algorithms is one class. It might be the most important class, or the only class in the intersection of all CS experiences, but each person's experience includes like 15 other courses. Some, perhaps even most of those should be systems. And systems classes should include substantial C programming.
in a scientific degree you still get taught how to use lab equipment and how to do physical experiments. that doesn't make it a trade school. i don't see why CS has this aloof attitude to actually teaching students how to do stuff.
I think the question is where's the line between "trade school" level practical instruction and "reinforcing concepts with practical examples." When I went through school, CS was taught in the Math department. In fact, not all universities had "Computer Science" undergrad degrees. Later on, my school introduced a "Computer Science and Engineering" degree that included a lot of hands on stuff (like what the previous commenter mentioned: implementing OSes, Network Stacks, Database data structures and algorithms, etc.)
But they didn't teach C programming. I actually taught the Intro to C Programming class in the Continuing Education department.
It might be the equivalent of a chemistry department saying "We'll teach you how not to blow yourself up in the Organic Chem Lab, but we won't teach you how to use a calculator."
But yeah. Seems every school is slightly different about where they want to draw that line. And most every school I've seen has more practical work than they did 40 years ago.
Lisp and Smalltalk existed before the C language, and don't have its damning flaws. Ada's also much nicer. As for the operating system, there are currently no good such systems that aren't very old. I use Emacs to largely avoid the UNIX sh. Ideally, a university would have its own operating system, but I suppose that would be too hard, in comparison to accreting another layer of shit over UNIX. Something such as Alan Kay's VPRI would be best: http://vpri.org
I didn't go to a university to learn anything about computers, fortunately.
Today one of the best "Not really Unix, but close" it's called Guix(SD) and it's bound to Scheme. And without C, forget about having a kernel and a Scheme compiler.
The best env to complete SICP it's, paradoxically, a Unix like system written in C with an Scheme DSL to set up the system declarativelly.
> Letter grades will be given as follows:
>
> * 90% - 100% of total available points => A
> * 80% - 90% of total available points => B
> * 70% - 80% of total available points => C
> * 0 - 70% of total available points => F
>
> Within each letter grade, there are +/- grades given at the discretion of the instructor. (Exception: there is no A+)
In my experience in undergrad "D" meant "you can get credit for this class but cannot use it as a pre-requisite for other courses". So that makes sense for graduate level courses.
I believe this course (or something close to it) was taught in the University of Kent when I was there between 2009 and 2013. Really got my Linux game up to the point where I could switch to it fulltime.
I took this class while I was in grad school! Ended up dropping due to reasons but the instructor was great. I'm pretty sure the course materials are up on YT as well.
The moment I read APUE, the website apuebook.com flashed into my mind. I've been following Stevens and Rago book since their first edition which was late 1990s.
Because a modern programming course page must have 30 MB link to 3 analitycs pages and have Facebook and Tiktok tracking and buttons. Nevermind that the main info is 1kB. /s
looks cool but this sentence "and all OS that belong to this family, such as Linux, the BSDs, and even Mac OS X" triggers me a bit because MacOS is the only one of those OS' listed that are certified UNIX.
Technically Unix is trademark, you have to pay to be Unix.
