Hacker News Reader

Comment by dfee | Hacker News Reader

The content taught here is the highest payout thing you can learn, in my opinion. Certainly more important than actually writing code or learning algos.

What this content covers should unlock iteration speed, which is the single greatest lever in learning and growing faster (on a computer). Thus it gives you more cycles to go back to improving your code, experimenting with algos, etc. Probably also highly correlated with upwards mobility in the software job market.

Great seeing this under a common umbrella I can hand to students and new grads.

View on HN

I have this feeling that the kids who appear better at uni are the ones who happened to pick up certain not-quite-programming skills before they started. Basics of networking, how installation of programs happens, how to use the command line, that kind of thing.

I looked over her shoulder as my wife was doing a CS degree, and I realised there's a bunch of these little things that make life a lot easier if you know them.

In my class 5 years ago, the differentiating factor was whether the kids who grew up online or not. Students like myself or my roommate who’d spent their formative years in front of a computer, not because they had to, but because it seemed like the thing to do at the time. I never realized how much I was learning during the time I spent scripting RuneScape bots and writing toy “viruses”, I did it because it was more fun.

I got my start writing RuneScape bots too! It's such a shame because speaking to the younger generation (I call them the TikTok generation) they don't have the same experience with the web the way we did. For them, the internet is closed off, a few big websites like Facebook, youtube, twitter. They use their phones primarily to access the web, and a laptop is exclusively used for school work; "A PC? Why would I need that when I can game on my XBox/PS5??". The internet really did change so much in the last decade, and in my honest experience computer literacy has gone down not up as we've all expected

>Basics of networking, how installation of programs happens, how to use the command line, that kind of thing.

um yea thats my job dude and i fought for it so other people should too these people waltzing in not knowing shot should not get into CS

One of those cases that some people are so unreasonable, you can't tell what's sarcas m

I sort of get that, in this day and age, it would probably seem a bit unusual for someone to show up at Stanford or MIT and be like "I've only ever used a computer to play video games but I think I'll major in CS." On the other hand, I also don't think programming had to be an all-consuming passion for the past 10 years as some seem to deeply believe.

I think there actually may be some of this. Both of my kids are in college right now, but I knew a lot of high school kids and their parents through the extracurriculars that my kids were involved in. The kids knew what the "hot" college majors were, including CS.

But they also knew the precise formula for college entrance, and were laser focused on getting into an "elite" school. Any activity that didn't contribute to that process was eschewed.

I'm not sarcastic.

There are a lot of students interested in CS who have very limited access to a computer. Most kids these days get a locked down ipad or Chromebook at school, and Windows' footprint in schools has massively shrunk over the years.

It's not like how it was when I was growing up. We spent $2000 on a Gateway PC that I had full admin access to, and unfiltered internet. Now that kind of money is being spent on cellphones in the household. Because I had that kind of access I was bricking the OS (and reinstalling it), Mailbombing people's AOL inboxes, putting Sub7 on Kaza and Limewire and remotely messing with peoples computers.

The computers at school were only networked my senior year. Even then they were basically wide open.

Me and my friends effectively operated a screwdriver shop out of whoever's house we happened to be at. We were trying to host game servers on whatever we could cobble together.

None of our families had cellphones because they were still only used by businessmen. Computing priorities were way different and how you were exposed to them was different as a result.

None of those opportunities are anywhere near as common now. Kids get devices in schools but they're basically bricks that log everything you do. Computer Labs are rare and their access is fully locked down. Most students first personal computing device is a cellphone, and more likely than not it's an iPhone. All phones are super locked down but apple's even more so.

The market has changed. The days of open computing are now relegated to the back of the line or for those who can afford it.

So it's no wonder a class like this exists. We see similar issues in middle school where students don't understand what folders are or where their files are stored. Phones and tablets make it so easy you never have to think about it. This also extends to collage as well.

>that kind of money is being spent on cellphones in the household

Okay then dont.

There's definitely a thing with CS that, at least at more elite schools, there's an assumption that you more or less know how to program--at least a language like Python--and you also more or less know your way around a computer well enough to use it as a tool for programming. (Or you pick it up quickly on the side along with your full course load.)

This is more or less unique among college majors outside of some arts disciplines like music. Yes, there's a requirement for some secondary school algebra and some basic science but an electrical engineering major could basically have never assembled a circuit before attending college and probably wouldn't be at any particular disadvantage.

And, per the original post, MIT is certainly one of the institutions that does this. The 6.001 MOOC(s)--basically intro to algorithms--teaches a bit of Python on the side but clearly you're intended to mostly learn it on your own.

(By contrast, back in the day, I took a FORTRAN course as part of a non-CS engineering major. The assumption was that you had never touched a computer before.)

I had a guitar tutor once and I asked him if I honestly had a chance to get into the Royal College of Music. He said absolutely, no problem, as long as you practice for at least two hours per day. Every day. For the next ten years... High-level CS is the same and I don't see any reason why it should be different. There is just no, or very little, time to teach introductory programming classes at most universities.

With the performing arts--perhaps music in particular--it's certainly the case that you mostly can't decide you want to do the music thing, except as maybe a very recreational activity for the first time in college. However, I'm not sure I'm sold that CS--more or less uniquely among technical fields (including electrical engineering)--needs to have the same level of informal prerequisites.

Am I unique in not romanticizing computer science?

I see it more as a trade. There can certainly be some beauty to it. I’m sure coal miners hold some of their own in special regard too.

Well after they spend 4-8yrs of their life learning CS, damn right they’re going to romanticize and gatekeep it every chance they get.

Meanwhile I agree with you, software engineering jobs are a trade 90% of the time. It’s why so many highly educated folks are being laid-off right now, while the doers keep-on building and making bank.

> while the doers keep-on building and making bank.

It’s spelled Doerr

Coal miners also do stuff like massively die in gas explosions and are kind of a poster child for labour exploitation. Wouldn't it be crazy if this line of work held the same prestige to hold in special regard?

There is beauty in just about any trade that is well done. To the extent this is romanticized is up to you. I'm not a big fan of the professionals that feel it is 100% trade. On the flip side, the 100% romantics are not ideal either IMHO - too focused on technology for technology sake.

It sounds like you are thinking of software engineering, which is an adjacent field often conflated. CS is about pushing current boundaries and inventing the future.

Software development is a trade, if all you aspire to be is a WordPress or frontend developer then you don't need a fancy degree, you can just as easily go to a 6 to 8 week code camp for that.

Computer science is a pathway for those that want to delve deeper, and that necessitates rigorous fundamentals in applied mathematics and information theory.

> Computer science is a pathway for those that want to delve deeper, and that necessitates rigorous fundamentals in applied mathematics and information theory.

I dare say that one can go through a whole career as a software engineer without spending a single semester learning about algorithms, in the sense that you just start learning about them in a JIT fashion if/when they become an issue, which is rarely.

Some of the O(X) trivia so much sought after in some interviewing circles is even fundamentally wrong when real world aspects such as problem size or CPU architecture come into play.

This is basically my career. I had a stable gig for my first handful+ of years after college and never much encountered the leetcode grind people talk about until recently. A lot of the O(X) stuff is self apparent when you're writing practical code: lotsa slow loops within loops == bad and should be avoided where possible.

When I started doing job interviews it was a little bewildering how much some companies focused on this. I ended up taking a job whose interviews focused on more practical skills and also stressed a good culture fit and understanding of development practices. It feels like a place I'll be happier.

I think you're right about the JIT aspect to this sort of thing--that's really what being an engineer is about in my experience. When you encounter a problem, figure out how to do it better. If my filter/sort/whatever is too slow for a specific application, I'll do some research and implement something more appropriate.

Computer science != algorithms. There's also the whole systems branch! If you ever find yourself thinking about TCP, virtual memory, system calls, frame buffers, shaders, signatures, interpreters, compilers, query planners, etc. these are also things you could have studied and practiced building in a CS program.

I didn't start programming until I was in college and did just fine in my undergrad CS at UW Madison.

MIT has an expectation that students would cover their programming skills via internships or outside jobs, and thus they focus on teaching CS which is quite hard to pick up on your own. Unlike frameworks or trends which change every 2 years, fundamentals are quite hard to change and can carry you quite far if you know how to apply it correctly.

My school handled this cleverly by taking people with prior programming experience into a Haskell sequence, which suitably kicked our asses to the same degree as what the first-time programmers were getting.

UWaterloo does this.

My college's CS program did the same, but with Scheme back in the day.

I can't complain, since I was introduced to Emacs along the way, which I still use heavily to this day. And while I don't really use Scheme anymore, it made Elisp trivial to figure out.

My CS course at the University of Sussex, UK did this (in 1988) with ML, the functional programming language. Plenty of us had already been coding in C or Pascal before starting at college. None of us had done any functional programming. I loved ML: it seemed all elegant and beautiful and magical.

When I hear people starting their CS degree with C++ or Java, it makes me cringe.

Which school was this? Was this UT Austin by any chance

But is it common for kids to be taught how to code before they come to uni? I would imagine it's not that easy to find someone to teach that sort of thing, so then the only kids who graduate high school with any tech skills are the ones who did it themselves.

Your point about engineering is exactly right. I built a working radio in my first term, having never done anything like it before, save for acing some physics exams with minimal electricity sections. When we came to coding, I had mucked about a bit with a computer, but I also found other students who'd worked at Microsoft. Wide wide range, and a lot of people of course ended up getting that fellow to email them the solution.

Even if it's more like hacking around in Python than being "properly" taught, I assume that it's pretty common for a technically-inclined and motivated high school student to play around with a Raspberry Pi. I imagine I'd be doing so if I were in high school today. In addition to books, there are also some pretty breezy intro to programming MOOCs out there that wouldn't be out of the reach of a smart high-schooler.

I don’t think that’s quite right. You’re not going to expect someone majoring in French to not have studied any French before college.

It seems completely reasonable to expect someone to be comfortable finding their way around a computer if they’ve chosen to major in computer science.

I’d also expect an entering electrical engineering major has studied more math than just “some secondary school algebra”. They’ve probably already studied some calculus or at the very least are ready to as soon as they start their first semester.

It’s a bit of a red flag to have no foundations in a subject you’ve decided to focus on for the next four years. That said, sufficiently motivated individuals can catch up and overcome their initial lack of preparation.

You have to put yourself back into your 18yo self, right? The kind of people who think a degree in management will make you a manager, and if they let you on to your course they must know what the requirements are and you must satisfy them.

At that time in your life your entire world has been school, and everything you did in school led to another thing in school. Why wouldn't you assume you'd get taught programming when you applied for a CS course, whose prereq was math that you did in school?

everything they teach you in a CS degree is useful and broadens your knowledge of the space, and all of it might potentially come in handy as your career develops, though much of it might not.

Doesn't mean you'll be a great programmer or archtect or planner or teacher. Right? you might drop it and go into something else.

Same is actually true of a management degree, everything they teach has been well thought out and is applicable to managing a company. Doesn't mean you'll be any good at it or work in all those departments. It is not a useless degree, though many useless people might pursue it.

>(By contrast, back in the day, I took a FORTRAN course as part of a non-CS engineering major. The assumption was that you had never touched a computer before.)

This was my "back in the day" experience as well, though I had a choice between C and Pascal. There was no expectation that anyone had any programming experience. I only had a touch of C64 BASIC knowledge going in.

> I have this feeling that the kids who appear better at uni are the ones who happened to pick up certain not-quite-programming skills before they started. Basics of networking, how installation of programs happens, how to use the command line, that kind of thing.

This one really stood out to me and highlights a change in things since then. That describes ALL of the CS kids during my time. We were the ones who a) had computers and b) did weird things like rebuilding kernals or futz around forever trying to get remote X sessions running.

A fact that blew my mind a few years ago was that, of the 13 software engineers on my team, only 3-4 actually owned a computer other than the work-provided one.

Yeah, I remember taking this machine architecture course with a friend who was getting a journalism degree and had never written any code or done anything more technical than playing StarCraft brood war before college.

One of the later assignments they gave us this "bomb" executable and we had to use gdb to pick it apart and modify the instructions or find ROP gadgets or something to make the code not "explode". He was my partner in the assignment and I spent most of the time trying to teach him what I was doing in gdb. And trying to express that, sincerely, he wasn't stupid GDB is just really hard and he didn't have the background knowledge to make learning it easier.

This doesn't fit my experience.

I mean, yes, this was me. I came in knowing most/all of this. I knew six (or more?) programming languages, had at least played with CVS/SVN, had installed Linux (read: fought with the Linux bootloader to get my AMD CPU to boot without crashing), had dipped my toe in a few open source communities.

But I was a tutor in college and I interacted with a bunch of people who didn't come in with any of this experience. Many of those people struggled, but I also know a bunch of people who came into CS knowing nothing, loved it, and went from zero-to-sixty faster than even the people who came in knowing a lot.

I'm still not sure I can identify what the ingredient was, but experience alone is not enough to explain it.

I went to college in the late 90s. Didn't even own a computer until I was a freshman (used my loan money to buy one). Math and science had always been my subjects, so I started college pre-med. But, this new computer I just bought kept sucking me in. I'd stay up all night reading how to make it faster, learn all the tricks, and finally make it do what I wanted through programming. Next semester I took a programming class just to see how it went, then dropped everything, and switched majors. I got a part time job writing custom software for local companies as a sophomore/junior (late 90s dotcom was just ramping), and I guess it has all worked out ok.

And in non-English countries, well, knowing English long before uni helps a fuck ton.

I sat with a talented developer whilst we wrestled with a threading issue this past week. I wanted to inspect the value of a variable within a method during execution and asked him to set a breakpoint. He didn't know how to do that in the IDE, which he'd been using for over a year. Debugging is indeed a skill which needs learning.

A talented developer who doesn't know how to set a breakpoint sounds contradictory to me.

Hi! I'm that person! Senior engineer, decade of experience. I've used debuggers in the past, both for running code and looking at core dumps, but I really don't find them to be cost effective for the vast majority of problems. Just write a print statement! So when I switched from C to python and go a couple jobs ago, I never bothered learning how to use the debuggers for those languages. I don't miss them.

What makes you talented?

> I never bothered learning how to use the debuggers for those languages. I don't miss them.

This could be causal.

You'd have to assume that the python and go debuggers do something that C debuggers don't do.

Or assume that python debuggers aren't as nice to use, or that python does not lend itself to inspecting weird memory and pointer dereferences, or a bunch of other possibilities.

I am also this person. I'm a systems programmer (kernel and systems software, often in C, C++, golang, bit of rust, etc)

What I find is that if my code isn't working, I stop what I'm doing. I look at it. I think really hard, I add some print statements and asserts to verify some assumptions, and I iterate a small handful of times to find my faulty assumption and fix it. Many, many times during the 'think hard' and look at the code part, I can fix the bug without any iterations.

This almost always works if I really understand what I'm doing and I'm being thoughtful.

Sometimes though, I don't know what the hell is going on and I'm in deep waters. In those cases I might use a debugger, but I often feel like I've failed. I almost never use them. When I helped undergrads with debuggers it often felt like their time would be more productively spent reasoning about their code instead of watching it.

Your list of programming languages excluded Java. Please ignore this reply if Java is included.

Are you aware of the amazing Java debugger feature of "Drop to Frame"? Combined with "hot-injection" (compile new code, then inject into current debug'd JVM), it is crazy and amazing. (I love C#, but the hot-injection feature is much worse than Java -- more than 50% of the time, C# compiler rejects my hot-injection, but about 80% of the time, JVM accepts my hot-injection.) When working on source code where it is very difficult to acquire data for the algorithm, having the ability to inspect in a debugger, make minor changes the the algorithm, then re-compile, inject new class/method defs, the drop to frame, the re-exec the same code in the same debug session is incredibly powerful.

Yes, that sounds pretty cool and it doesn't take a lot of imagination to see the utility in this. I've done a lot work on lower level software, often enough on platforms where the debuggers are tough to get working well anyway.

The plus side of less capable tooling is it tends to limit how complex software can be--the pain is just too noticeable. I haven't liked java in the past because it seems very difficult without the tooling and I never had to do enough java to learn that stuff. Java's tooling does seem quite excellent once it is mastered.

This part: "I haven't liked java in the past because it seems very difficult without the tooling"

If you are a low level programmer, I understand your sentiment. A piece of advice, when you need to use Java (or other JVM languages), just submit to all the bloat -- use an IDE, like IntelliJ, that needs 4GB+ of RAM. The increase in programmer productivity is a wild ride coming from embedded and kernel programming. (The same can be said for C#.)

I think there's a sort of horseshoe effect where both beginners and some experienced programmers tend to use print statements a lot, only differently.

When you're extremely "fluent" in programming code and good at mentally modelling code state, understanding exactly what the code does by looking at it, stepping through it doesn't typically add all that much.

While I do use a debugger sometimes, I'll more often form a hypothesis by just looking at the code, and test it with a print statement. Using a debugger is much too slow.

> Using a debugger is much too slow.

This varies, but in a lot of environments, using a debugger is much _faster_ than adding a print statement and recompiling (then removing the print statement). Especially when you're trying to look at a complex object/structure/etc where you can't easily print everything.

I think there is a bit of a paradox, debugging can seem heavy, but then when you’ve added enough print statements you’ve spent more time and added more things to clean up than if you had just taken the time to debug, well, you should have debugged. But you don’t know until you know. This seems to also appear with the “it would’ve been faster to not try to automate/code a fuller solution” than address whatever you were doing.

> using a debugger is much _faster_ than adding a print statement and recompiling (then removing the print statement)

Don't remove the print statement. Leave it in, printing conditionally on the log level you set.

In what way is using a debugger "slow"? I find that it speeds up iteration time because if my print statements aren't illustrative I have to add new ones and restart, whereas if I'm already sitting in the debugger when my hypothesis is wrong, I can just keep looking elsewhere.

I find I use the stepping debugger less and less as I get more experienced.

Early on it was a godsend. Start program, hit breakpoint, look at values, step a few lines, see values, make conclusions.

Now I rely on print statements. Most of all though, I just don't write code that requires stepping. If it panics it tells me where and looking at it will remind me I forgot some obvious thing. If it gives the wrong answer I place some print statements or asserts to verify assumptions.

Over time I've also created less and less state in my programs. I don't have a zillion variables anymore, intricately dependent on each other. Less spaghetti, more just a bunch of straight tubes or an assembly line.

I think it's possible that over the years I hit problems that couldn't easily be stepped. They got so complicated that even stepping the code didn't help much, it would take ages to really understand. So later programs got simpler, somehow.

It’s because we moved to request-response, and allow for deep linking / saved states. Soo the state of the session is more easily reproduced

I find I use the stepping debugger more and more as I get more experienced. Watching the live control flow and state changes allows me to notice latent defects and fix them before they ever cause actual problems. Developers ought to step through every line of course that they write.

Most of what I worked with code wise growing up was either very niche or setup in such a way that debuggers weren't an option so I never really used them much either. I don't understand their appeal when print statements can give you more context to debug with anyway. I'm definitely no senior but I'm used to solving things the "hard way" as one developer told me. He wondered how I could even work because of how "bad" my tools were but I didn't know any better being self taught and with certain software it's just not compatible with the tools he mentioned.

It depends what you're doing. Sometimes inserting a print and capturing state works. Sometimes you're not sure what you need to capture, or it's going to take a few iterations. That's where pdb / breakpoint() / more interactive debuggers can be very helpful.

True. A talented developer abuses the hell out of breakpoints by using hit counts, conditions and trigger points.

As an untalented developer, I used to make heavy use of debuggers, and knew them well. Currently, as a still untalented developer, I've fallen out of the habit of using them and don't know how to for my current toolchain.

Neither situation was at all related to my talent (or lack thereof).

You don’t need breakpoints all the time though. If you’re familiar with the code (or just “talented”), you might have an intuition for what the problem is and it’s faster to just think through it (and maybe write a few quick prints) instead of interrupting your train of thought setting breakpoints, clicking continue, waiting for the IDE to freaking load the debugging session (cough Visual Studio), rerunning the test, etc.

Besides, every IDE has a different way to debug, so they might just not be familiar with the interface. I can’t tell you exactly how to debug in VSCode even though I’ve used it the most. I’ve had to run a debugger only a handful of times in the past couple of years and it’s always for codebases that are more tangled (e.g. .NET where there’s interfaces everywhere).

+1. i just used a debugger today at my work for the first time in 4 years by coincidence. normally i just throw a couple prints and rerun the test and today i was reminded why. takes like 8 minutes to run the test in debug mode. lots of useful info in there but usually i can guess where the error is without it. it was indeed good at pinpointing the sigsegv though.

There is a world of programming where debuggers don't serve much purpose. Individual microservices are usually trivial, but push complexity into the interactions between services. Debuggers are not much use there; distributed tracing is more relevant. Functional programming, which is a growing part of the industry, really emphasizes code you can easily reason about. That's arguably the whole point of functional programming. Debuggers don't get much use there either.

I'm not a talented developer but I did spend my day on an F# piece of code that builds a databale based on a record type using reflection (and eventually realized it was going to need to be recursive) and I probably would've just quit if I wasn't allowed to use a debugger.

Now maybe if I was better that wouldn't be the case, but even the cleanest "wish i thought of that" functional code i've seen still looks like it'd be easier to fail fast using a debugger with.

In fairness though, I will admit I use the debugger a lot less when i'm not screwing with reflection on generic types or whatever because runtime errors just happen a lot less in functional styles. Usually if it compiles, it runs, because the compiler can sanity check the code better than you can.

> I'm not a talented developer

> [uses F#]

That has to be humblebragging. The average .net developer is terrified of or doesn't even know about F#.

It's an interesting phenomenon because F# is far easier to learn than C#.

Perhaps if you already know C#, otherwise I doubt it. Of course it depends on ones prior experience, but F# is functional but still requires you to understand OO in order to interact with the framework.

I think it's harder if you already know C# or some other OO language. I really think it would be easier, or about the same, to teach a raw beginner the basics of F# vs C#.

The only reason F# winds up feeling harder isn't so much how F# works, but simply because the entire dotnet environment was built for C# first, so you do need to know how to handle the C# style. I do think that if you could just pick one and then suddenly have every library support it's styles, F# would probably be easier overall because it's just got a lot of nice features built in that make updating your code so much easier.

F# has two ways to invoke functions, ‘f a b’ and ‘f(a,b)’. You need to know when to use what. There is no way this is simpler to beginners compared to having one consistent way.

C# is not a simple language, but F# has basically all the complexity of C# with OCaml on top.

Either C# or OCaml would be simpler to learn, although the combination is powerful.

I don't know F# but the reference only mentions the `f a b` syntax.[1]

`f(a, b)` looks like a call to a function that takes a single tuple as its argument. So I would expect `f` to have the type signature `A * B -> C` instead of `A -> B -> C`. Is my intuition wrong? If it is, then what does F# use the parenthetical syntax for?

[1] https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...

Methods from the .net framework and other libraries are called with a tuple of argument, since they are not compatible with the native F# was of calling functions.

I mean to be completely bad faith pedantic, yeah that's still f a b, but obviously not the point being discussed here.

This to me is a pretty simple thing to explain and deal with.

F# enforcing a lot of good practice code style stuff (order matters for example pisses off long time devs who already have styles, but prevents SOOOO much stupid bs from beginners) and basically eliminates runtime/chasing variable state errors completely so long as you can stay within style. Yes it'd be nicer if there was only one way to invoke functions but if i had to take a tradeoff I think it's a pretty easy one.

It is an issue that yes, like your example, you're often stuck ALSO learning OO because "oh you want to use X library, well that's OO so...", and even then you can isolate your mutable/OO areas really well, but this is more of an issue with it being an second fiddle language. If F# got F# specific libraries for all the C# stuff out there tomorrow I think it'd take off and most people would never look back.

If we're talking basic business logic/beginner programmer stuff, yeah I think F# offers a lot of stuff that makes it flat out easier to use. And if you want to point out complex issues, I feel the biggest one is that something that's intuitively much easier to understand in OO (create a variable/object, populate it on each iteration of a loop depending on logic), can feel daunting as hell in F# (fold).

Knowing a good bit of Rust helped me considerably, due to the commonalities of being expression-based, pattern matching and sum-types. F# almost feels like a more functional and GC'd Rust.

F# is heavily based on OCaml and Rust was heavily inspired by the ML family of languages, and I've often heard it described as an ML without GC and with memory management and a C++ style syntax.

You're noticing a very real relationship.

This was me - my first .net language was F# (although I'd dabbled a tiny bit in C#); it was hard to learn the .net standard library as well as trying to learn functional idioms...

I don't agree, because learning F# is essentially learning two very different languages at the same time: first OCaml from which it was initially an implementation, then C# for all the object/CLR layer.

It's easy for people with functional programming knowledge, or who had OCaml as their first programming experience like I did at university, but for people without those exposures I can understand the difficulty.

I’ve encountered the same thing. I’m a terrible programmer but find f# way clearer than most C#/java. But I work with tons of great developers who would rather cut off their finger than learn f#, it bothers me because it exposes some fundamental difference between us I dont like to believe exists.

Job vs craft. Or, maybe, they just don’t want to pollute the codebase with a new thing that breaks. Consistency is a virtue in old codebases.

> I'm a terrible programmer

Oh? Did you win some award? I'm curious as to how you're determining this?

Not a humblebrag. I’ve noticed I struggle with tracking lots of variables and states compared to many fellow developers. I’ve sort of tried to turn this weakness into a strength, by making code simpler, but sometimes I make it too terse because I like code golfing.

Is the average .net developer terrified of F# because they're not talented enough, or because it's different?

It's 100% the latter. I get "ok we don't want to mix codebases" and that's fine, but if you can code in C# you can probably get up and running in F# in a week, maybe a month if you struggle with some of the concepts.

One major issue I do see coming from the C# side is "well how do I do this then?!", which often the answer is "you don't, because you don't need to" or "well what if it's more performant to do it mutably!" well then thankfully F# can absolutely do that.

If you keep an open mind it's really a very clean and simple language, but in an age where half of development is importing 8 well known libraries, not being the main supported language is a major weakness.

I normally write C++, but I've also written in Rust, Python, Ruby and bunch of other languages. I've never had trouble with a programming language until Haskell, and had to accept that I'm just probably just not smart enough to do it.

However, I wrote my first thing a port of a small C# tool of a couple hundred lines, to F# in about an hour. It's been about a week now, and things are considerably smoothing out.

To be considered niche, the F# tooling has been great. Also, having the .NET libraries available adds a lot of built-in capability.

In my experience most developers remember how hard it was to learn their first language, and worry that the second will be just as hard

It's really not. I'm quite terrible from any industry perspective.

F# isn't hard, it's just different. Hell in many ways i'd argue it's much much easier once you get used to it. It doesn't have the support C# does so often you're stuck with a library that WILL work but doesn't have documentation for doing it in F#, and that can lead to struggles, but that's not really a sign of being a good coder.

Most dotnet developers could probably code circles around me in F# if they knew it existed/gave it a chance.

Personally I stuck with it because it had the low code look of python with strong typing. It took a bit to wrap my head around some functional stuff (basically map/iter = foreach and if you want to update something on each loop you probably want a fold, or more likely a built in function), but once I got over that hurdle it was pretty smooth sailing.

The irony is that by far the hardest part is the library thing, which your average dotnet dev would handle WAAAAY better than me.

Agreed, when I commented earlier I was also thinking about mentioning something similar with regards to classes of bugs due to interactions between systems.

Unless you have a setup where you can easily run one system with a debugger attached while connecting it to everything else, you’re basically restricted to running a debugger for bugs that can be reproduced locally.

The distributed tracing point makes sense, but I think debuggers are still quite useful for functional code. Though maybe less commonly needed than just the repl.

I read a long time ago, that either Kernighan or Ritchie said they never use a debugger and just sprinkle printf() statements.

Concluding that using printf to debug is superior to using a debugger would be a mistake!

I’ve been programming in C for nearly 20 years and primarily used printf for debugging for the first 12-15 years, and have used debuggers more and more. I use Emacs, and its gud mode is so nicely integrated into everything that using gdb is truly much, much faster than the alternative. I don’t use print debugging at all anymore.

It takes less time and cognitive overhead to just stop the program on the same line you would have inserted your printf, but you can now inspect the entire program state.

Obviously I’m not saying anything revelatory if you use an IDE on a regular basis… I guess this comment is for the folks who eschew IDEs.

This works well mostly and I use this. I usually implement a logging system where I can enable/disable individual components but use a debugger to examine functions which are not behaving as intended.. or core dumps. Usually in connection with an unit test that fails or started failing caused by my changes to the codebase that I'm working on.

Logging alone is fine, but it can often be difficult not to drown in information. I do embedded programming in C mostly.

I didn't use debuggers since switched from C to Rust. By the way I switched from emacs to VSCode and I do not know how to debug here. I never used debugger with lisp. Debugging is a language dependent technique.

I like debugging Lisp because the debugger is built in. A break here, an invoke-debugger there and the REPL takes me where I want to be.

There are large categories of software engineering where debuggers are not used that much.

I work on compilers and debuggers are more of an hindrance than help when trying to fix a compiler bug.

I believe there is a similar situation for distributed systems.

Meh. I use the right tool for the job, and most of the time, a simple print statement put in the right place beats any debugger. Certainly the debugger has helped me in the past, but maybe one or two times only. Besides, putting a print statement costs nothing, and one knows exactly how to do so. Debuggers vary wildly: terminal, IDEs, etc.

I don't usually use breakpoints in part because I use neovim and in part because... I seldom truly need them. Who are these people and what are these problems where stepping through method calls etc is actually necessary? I find it hard to believe. I've been successfully programming and problem solving this way for over 15 years.

I haven’t been shocked that fellow engineers don’t know how to use a debugger for at least ten years. Most jobs in the industry can be done adequately without getting into tools that low level.

Maybe rare but you may be very skilled at understanding structure and finding solution but knowing nothing about tools. As long as you're either one of them.

How would a breakpoint help with debugging a concurrency issue?

Well. a big part is curiosity, and apparently he isn’t curious not interested in what his tools do.

I used to read every help file on windows / visual c++, the FreeBSD manual, plowed through the file system and tested this it. Just because I was curious

There’s limited time. One cannot vey curious about all the stuff related to programming, so we must be selective.

Sure.. that’s the story of the lumberjack with a blunt axe.

Nah, debuggers are useful but hardly necessary to do your job well. People have been productive at programming long before they had many useful tools at all, the most important thing will always be how well you understand the program you are writing and not how you use your tools.

It's interesting. I mainly use functional-first languages, and I rarely need breakpoints. Programming is much more compositional with certain languages.

I agree you should know how to use a debugger, however will also note that some companies mandate use of a specific IDE (or heavily encourage).

I have seen devs scoff at the thought of print debugging, but I recall that in systems programming there are many times you can’t use a debugger or need to rely on other tool.

I’d rather schools teach the concept of step debugging vs runtime debugging. Teach students to try to understand the code, make hypotheses, and verify them.

I have seen some people use a debugger solely because they only know how to step debug. Meaning they start from main or another entry point and step through every line of code.

My point being that, you can’t judge a developer by if they use print statements or a debugger. Judge them by the methodology of how they debug.

> I have seen devs scoff at the thought of print debugging

Next time they do, ask them to recommend a better method of debugging that works across generally all languages, compilers, IDEs, and platforms with next to zero configuration.

Print debugging is one of the best ways to learn about buffering and the difference between stdout and stderr.

The key thing about print debugging for me, that I've never seen a typical debugger handle well, is what I like to think of as "temporal debugging":

Taking a program trace from the print debug statements, grepping through it repeatedly to filter down to certain events of interest, looking at the interleaving of those events, and figuring out the order that things happened in to cause it to go off the rails. That sort of thing. (To be fair, time-travel debuggers can start to get at this, but those are pretty uncommon. Traces, as you say, work almost everywhere.)

Or better yet, compare the traces between working and non-working runs to see how they differ. I've looked at diffs of traces this way before. (Sometimes I'll first use a small script to renumber pointers in traces by order of appearance.)

I've also used this sort of strategy before for debugging rare threading or other non-deterministic issues. Have the shell run the program in a loop, saving each run's trace and results to a different file, go off and get lunch, come back and see if anything failed. Then look to see if any of the runs failed and look for the structural differences between the working and non-working traces.

I can't imagine sitting and stepping through in a debugger 100+ times in the hopes that maybe this time, it will be the run that's just different enough to trigger the bug and that the debugger itself won't prevent the issue from manifesting. Not to mention, trying to remember the steps from all the good runs and spotting where the bad run goes bad before you've stepped to far. No thank you.

I think people really underestimate print debugging. Debuggers are fast and easy for simple bugs, sure, but there's powerful stuff that you can only really do with printed traces.

> I can't imagine sitting and stepping through in a debugger 100+ times in the hopes that maybe this time, it will be the run that's just different enough to trigger the bug

Isn’t that where things like breakpoint conditions, data breakpoints (“break whenever X value/field changes”), and dependent breakpoints, work pretty dang well? You just set up the appropriate situation and let it run until it breaks

Those help in some situations, sure. I'm talking about the non-deterministic things like unusual race conditions, where the problem only manifests rarely. Conditional breakpoints could certainly help you detect when things have broken, but you'll often be well downstream of the root cause by then. Though I suppose tracepoints could help with that. So I'll concede that you could probably do something similar in a powerful enough debugger with sufficient effort.

But one thing that I have found helpful in the past has been aggregating the information from the traces across runs. Comparing good with good and bad with bad to classify the commonalities, and then compare good with bad to see how they differ.

Yeah. Also for any kind of race condition a debugger is usually pretty useless. Also most memory corruption problems. The debugger has a place but so does printf debugging.

> I agree you should know how to use a debugger, however will also note that some companies mandate use of a specific IDE (or heavily encourage).

The debuggers in most popular IDEs (IntelliJ IDEA/any JetBrains IDE, Visual Studio, VSCode, Eclipse) work the same way. You set breakpoints (typically by clicking somewhere around the line number), step into and out of functions, and look at the memory state. If you learned how debugging works in IDE X, you can easily switch to IDE Y without having to learn much.

The biggest hurdle for beginners when using built-in IDE debuggers in my experience is the requirement to set up the debug run configuration to properly execute their program. Even though this amounts essentially to "how do you run the program on the command line? Write that in the IDE configurator", newbies don't know how to run the program from the command line (and can't debug any startup errors they might get), so can't properly set up the debugger in their IDE, and revert back to print debugging everything.

> I have seen devs scoff at the thought of print debugging, but I recall that in systems programming there are many times you can’t use a debugger or need to rely on other tool.

Not just systems programming, but fixing issues in scaled production systems as well. Have fun attaching a debugger to the process that got killed twenty minutes ago when the spot instance it was running on got reclaimed. If you don't collect telemetry, you're blind. Debuggers are a luxury that you get to enjoy for issues you have before you ship.

I learned this stuff without having people show me.

I went to Purdue over a decade ago and we had a 1 credit hour lab that taught this stuff. Unix command line, git, bash, and finally some python.

Like you said, it's been a complete game changer. I feel these skills continue to differentiate me from my peers in terms of how I can attack arbitrary problems bravely to this day.

They still teach this stuff at Purdue. I graduated a few years ago and by far the most important class was about how unix works, moving around the command line and finally introducing us to vim

<3 Me and a few others created this course in 2014. Glad you found it useful! I got so much joy out of the content creating the content for the lectures and labs.

Indeed. While I think learning algorithms and ds is a non-negotiable thing, in 90% of the companies out there in 90% of the situations one will never have to write a binary search from scratch or implement a queue from scratch. On the other hand, profiling, debugging, glueing things together via bash, etc., that’s what distinguishes you from the colleges who only write passable code.

But writing implementing some of those basic data structures is some of the funnest things to do in uni.

I dropped out after a year of college and have since weaseled my way into a dev position, your observation could not be more true in my experience. I've since strongly considered going back to school for a degree, but as interesting and probably useful some of the material may be, I'm not convinced it's worth it as an investment into making me better at my job.

If only I could use 529 funds on some of these online course providers.

Not sure if that fits, but it reminds me of Gary Bernhardts "Unix Chainsaw" talk

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

It's all about leveraging "simple" cli tools and combine their powers to cut through work very swiftly. The opposite of many days for many people.

Reply on news.ycombinator.com