aurelius

None of them. Study Knuth. Study the Intel manuals. Study “The Art of Multiprocessor Programming”. Study compilers. Study TCP/IP. Study algorithms and data structures. Write lots of code for all of those things.

Disregard the noise. Ban yourself from reading blogs and magazines and tech news. Focus on what is fundamental to the field. Look where nobody else is looking.

I'd like to give you some advice based on my own experience, and without making too many assumptions about you and what you haven't told us about your situation.

I absolutely believe there is a way for you to get through this. Don't be discouraged!

The first thing you must do is to kill the negative thought train. Don't panic, don't assume your career is over, that you have no hope, that it's going to get worse, that people are going to find out, that you'll get fired, etc.. Whatever you're fearful about as a result of realizing you're burnt out, try to set it aside for now because you don't need any more stress or worry. It sounds like you have time to think about what to do, so take that time, and don't put yourself under any pressure. Accept the state you're in. It's ok. This happens to many, many people, and you're not the only one. Moreover, your world doesn't sound like it's about to end. Relax about it, as much as you can.

I would echo what some others have said here about telling your boss/team: don't. What I think you need to do is look at what your day-to-day job is like, and see if there's anything you want to change. Is there anything that's really dragging you down? Do certain tasks or projects drive you crazy or make you feel depressed? Are you unhappy with your role in general? Do you hate your office and need to move? Is WFH making you unhappy, and you need to be back in a real office? Try to ponder it all, see if there's something you could change that would give you some quality of life improvement. When you think you have something, take that to your boss, and see what they can do about it. Don't engage in self-enfeeblement when you have that talk. You're entitled to set boundaries for yourself and ask for a change without having to divulge anything about your personal state of mind. Just say plainly that you're not feeling happy in your current role, and you'd like to give something else a try (i.e., whatever alternative you're going to present). Ask if that's possible now or at some point soon. If not, ask if there's something else available right now that they could offer you because you feel like you really need a change. Consider the options, but only choose one if it appeals to you, not just because you think need to choose one.

If it's a hard no from the boss or if there are no good options, then ok, no problem. Consider your next options. A job is a job. If things aren't so bad where you're at, then maybe it's worth staying. Ask yourself if perhaps you are too emotionally invested in having a "great career". If so, work on detaching emotionally. Show up each day when you have to, and leave when you can. It's ok to do a good job, and do it for the pay check. You don't have to accomplish anything great. You don't have to break your back for your employer. If you stay where you're at, look at ways that you can change little things to give yourself some feeling of agency and autonomy. For me, I had schedule flexibility, so I engaged in a daily act of rebellion where I would sleep in, show up in time for the daily stand-up, then do what I could until I felt like I was done for the day, and then I went home. If you don't want to stay where you're at, then take time to think about what you want to do next.

I can recommend seeking professional help. A good therapist is a very valuable disinterested third-party who can help you think everything through. Unless your situation is in dire straits, the best way forward is to make small but well-considered steps that will help create emotional and psychological space for yourself to heal. Oftentimes, what we think is the one problem causing us to burn out isn't actually the only problem contributing to the situation. A therapist can give you perspective on that. Perhaps anti-depressants might be a help for you, but a therapist can help you figure that out too. Don't sign up for the drugs straight away unless it is clearly needed.

I can also recommend walking, every day if you can, for as long as you're able or it remains enjoyable for you. Wooded areas and around lakes are great to walk around, but anywhere will do. It will help you relax and mull things over. It really will. Listen to music if you like, but also try it without. Stop and sit along the way. Take in the sky, the birds, the trees, the landscape. Just enjoy being there, and the beauty of nature. Think about whatever's on your mind, but don't force yourself to think of a solution. Let your mind wander. Space out. Relax.

Over time, you will be able to figure out what you need to change. It took me a couple of years, to be honest, but that's fine. It's not a race. The building (i.e., my life) wasn't burning, so I just focussed on taking my time because I didn't want to change too much too soon and end up back in the same hole down at some point down the road. I took care to sleep well (but not too much), walk regularly, and try do things I enjoyed (or used to enjoy). No pressure. If I didn't feel like doing anything intellectual on a particular day, I didn't. I got a lot of mileage out of housework, cooking, and walking on those days.

I believe you can figure this out. Hang in there, my friend!

A good manager should.

How ironic is it that the Haskell Research Compiler is written in Standard ML, and not Haskell? Joking aside, SML is a great language, and often overlooked, so this is good to see!

1994-1998 was a bad time for C++. Stepanov had just come along with the STL idea, and there were various competing implementations of it. And I don't think I need to say anything more about the travesty of MFC other than to acknowledge its mere existence.

C++14 (the latest standard) is a far better language than C++ in the '90s, and it really does beat C when it comes to abstraction capabilities, type safety, and standard library functionality. C++11 also defined a standardized memory model which is extremely useful for writing multithreaded code.

Yes, C++ is not perfect -- the C++ standard library lacks a lot of functionality found in the libraries of other languages; there is a lot of complexity in the language that one must master to really "know" C++; the language itself has dark corners and disappointments; and so on. No language is perfect, and every language permits bad code.

I've been working with C++ full-time for the past three years. I didn't know much about the language before then (I was a "C 43var!" guy), but had heard all the horror stories about it. Now, I'm convinced that it's probably the best general purpose programming language available to date. It combines the full power of the machine with very expressive abstraction capabilities. Having seen what can be done with C++, I decided to study harder and try to master it.

I think this last point is ultimately what puts people off, and leads to a lot of FUD about C++ -- it takes hard work to master the language and the tools to work with it. Nobody really wants to do that, not when there are seemingly viable, and easier, alternatives. Instead, people are more willing to invest huge amounts of effort and money to try to scale up those alternatives if it means they can avoid the complexity of a language like C++. That's fine, I guess, we all have to make the appropriate engineering trade-offs, it's just unfortunate that many people fall into extremism about it in order to justify their attempt to simplify the reality of computing (which is actually considerably complex).

What comments in support of the NSA? Any comments in support of the NSA here are IMMEDIATELY flag-killed by the HN Nazis who love to suppress any kind of free speech they don't agree with.

I know someone who used to work at an algorithm trading firm and did electronic market making. He said they used to go to great lengths to program their algorithms to try to spot this sort of manipulation, but it's a hard problem because you're fighting against a cloud of bad traders who are coordinating their efforts across multiple market centers.

I have to say, the regulatory dept. at the exchange I work for does an excellent job of monitoring for any funny business. They have some nifty real-time tools that are scriptable and can replay the state of the market at any point. It's really cool stuff!

Algorithmic trading is intrinsically neither good nor bad. It's kind of just a natural progression in the markets once easily programmable computers and high-speed networks came along.

How algorithmic trading is used, however, is another story. Humans are still the ones who bring the intent to technology, using it for good or evil. But it may interest you to know that a lot of malicious trading in the markets is not done by algorithmic traders, but by teams of manual traders working in concert to place manipulative trades that cause the market making algorithms to move the market in certain ways. (Source: I work at an exchange, and this is what our regulatory and compliance dept. says all the time.)

I think you've taken a pretty narrow interpretation of "reliable software". It seems more reasonable to think that Bjarne was speaking at a general level, i.e., the idea that software written in non-garbage collected languages tends to be prone to memory management errors on the part of the programmer.

This has been a common meme for the past 15 to 20 years precisely because it is so easy to forget when a block of memory needs to be freed. However, the mechanisms of reference-counted smart pointers, RAII, and clearer ownership semantics in the language, go a long way to help mitigate the common manual memory management problems in C++.

The downside, of course, is that you have to know how to use these ideas to write "reliable software", and C++ does not make it easy. It's pretty much impossible to go from reading the standard to implementing correct and optimal C++ programs. There are so many gotchas, corner-cases, and features which require much study and experience to truly understand.

Jarvis from Iron Man, or KITT from Knight Rider.

Neural networks are impressive only in that they are able to give any kind of meaningful results at all. In the end, they are only a poor mimicry of real machine intelligence, and not much better, conceptually, than plain old nonlinear regression.

Nobody has been able to determine what the structure of a neural network should look like for any given problem (network type, number of nodes, layers, activation functions), how many iterations of the parameter optimization algorithm are needed to achieve "optimal" results, and how "learning" is actually stored in the network.

Statistical learning methods are obviously still useful, but I think the field is still wide open for something to emerge that is closer to true machine intelligence.

I think your views on the GPL are spot on. At least we can agree on that.

So, the reasons for not using "SBCL" have nothing to do with "good enough". It's simply about "not mine".

Kaz, the C programming language isn't yours either. My point is that Common Lisp is supposed to be a general purpose programming language with power far greater than a primitive language like C, but you chose to implement TXR in C simply because C makes it much easier for you to accomplish your goal than Common Lisp. I'm just trying to point out the obvious, which nobody from c.l.l. seems willing to admit.

> why didn't Kaz use SBCL or CLISP?

Why should he?

Kaz invested a bunch of time implementing a whole new backquote implementation for CLISP, but it's still not good enough for him to use CLISP to implement TXR? It doesn't make any sense!

Any right-thinking programmer should care about inconsistencies such as this. If I'm evaluating a programming language, and I see someone in its community writing their own language implementation to support an application that could've easily been written using one of the standard language implementations, then it looks to me like the standard implementations aren't mature enough or trustworthy enough for me to use for my application. Not only that, but it suggests that maybe this particular language isn't as good as its advocates claim, especially if I have to drop back down to C in order to meet certain requirements (e.g., portability, speed, wider understanding, etc.).

But any right-thinking programmer already knows that lisp is not worth wasting any time on. It's dead, and people like Kaz, and projects like TXR, are going to make sure it stays that way.

Every single Python project you stated simply proves my point. They are Python compilers of some sort. TXR, on the other hand, is a data processing language implemented in its own lisp which is implemented in C. In other words, TXR is an application of lisp, not just a compiler or interpreter like those Python projects you listed. So, all your examples are irrelevant.

TXR didn't need its own dialect of lisp. So, the question remains: why didn't Kaz use SBCL or CLISP? They're good enough for c.l.l. kooks like him to recommend to everyone else, but why're they not good enough for him to use?

Because some random guys implement their own language in C? Why do we have Python, Ruby, Rebol? There was already PERL or AWK or ... Somebody decided to write their own scripting language. So what?

When a Python advocate wants to do some data processing, do they first write their own Python implementation in C? No. When a Ruby advocate wants to make a Rails website, do they first write their own implementation of Ruby in C? No.

Several fine implementations of lisp already exist that compile down to machine code and, if the lisp community is to believed, have performance "close to C". So why does a lisp advocate feel the need to re-write lisp in C for a project that didn't actually need it? The lisp community would have us all believe that lisp is the "programmable programming language", and all the other rhetoric about how every other language has just stolen ideas from lisp, etc., etc.. They all truly seem to believe that lisp is something special. That's why I find it laughable that someone like Kaz Kylheku, a 15 year veteran of comp.lang.lisp, decided not to implement TXR by using a pre-existing lisp implementation.

The point is that lisp advocates rarely seem to use any of these lisp implementations to do anything noteworthy or useful. They always seem to fall back on C, or some other language that's more "widely available" or "has minimal dependencies" or "has more potential contributors" or "can be more easily compared with other similar programs".

I find this hypocrisy to be quite intriguing.

I don't buy it.

TXR is not built "on its own Lisp", it's built on C. If you believe that lisp is so great, then why didn't you just use ANSI Common Lisp? Why is TXR even necessary when I can do all the same data processing stuff in Perl, which is far more versatile and ubiquitous?

And all this nonsense about writing TXR in C because it's "more widely understood", "low dependencies", "easily packaged" - after 15-some years of advocacy in comp.lang.lisp, it's laughable that defsystem, asdf, and SBCL/CLISP/CMUCL aren't good enough for you.

Lisp is either as good as all the Naggums, Tiltons, and Pitmans of c.l.l. proclaim, or it's not. By writing TXR in C, you've just proved that it's not.

Kaz Kylheku is one of the kooks from comp.lang.lisp where lisp is the One True Language. The funny thing is that TXR is written in C!

Kaz: How come you didn't write TXR in lisp?

What an offensive, restrictive, and anti-free software license! Too bad - this might have otherwise been a useful piece of software. The current license renders it toxic.

That's right. In all of history, the single most civilizing influence on the world has been the Catholic Church. Even with all the abuses and excesses, I don't think this can reasonably be denied.

Oh, look! Another Hacker News pedant come to pick meaningless holes in someone's comment.

I didn't say I was an expert on parenting. Did I?

Did I also say that teenagers are always and everywhere uncivilized savages? No. I made one over-the-top statement equating teenagers with cavemen, so I guess that's worth pointing out because it obviously proves that my entire comment was wrong, especially since that one statement can't be applied universally across time and space. Jeez...

Look, I've seen more than a few reasonable teenagers, but that's only because I roll with orthodox Catholics who actually believe what the Catholic Church teaches (without whining about it), and believe it's important to teach their kids how to be civilized. It's noteworthy that those teenagers only have dumbphones, if they have a cellphone at all.

So what if different cultures raise their kids differently? How does that negate anything I said? The children of one culture are born just as uncivilized as the children of any other culture. Civilization comes only from hard work. If you're a parent, imparting civilization to the uncivilized requires the right tools. If you're ok with giving your kid a smartphone, then it makes sense to have a tool to reel them back in when they can't resist the urge to abuse the freedom you've given them.

So, go take your pedantic inability to reason clearly, and participate more fully in whatever culture of deficient civility into which you were unfortunate to be born. I'm sure it'll turn out fine.

By definition, they are uncivilized savages. They are born not knowing how to behave in a civilized way. They also act like it too, from time to time.

Note that I explicitly and carefully said: "Unreasonable savagery can not be made civilized through reasonable discussion." The only reason that children can be taught to be civilized is because they do have some faculties of reason, and those abilities get stronger with age and appropriate training. When they are young, children learn best by imitation. So, of course, if a parent acts like savage, the child will too.

However, what we were talking about was the appropriate response to those times of "unreasonable savagery". So stop being a pedant, and changing the subject. Is a smartphone crippling app an appropriate tool for a parent to use in response to a teenager who is acting like an uncivilized tool? Absolutely. Is your view on children disconnected from reality? Absolutely. Do you also have wacky views on crime and punishment? I'm going to say yes there too.

I don't trust unreasonable savages. Neither should you.

I don't think you or jpfielding have any real experience raising kids. That's pretty clear from your smug assumption that children are reasonable people who will see the error of their ways if only their parents took the time to explain it to them and pander to whatever way the child wants to go about subverting parental authority.

Let me clue you into reality. When kids pop out, they are uncivilized savages. It takes a good 25 years (on average) before they stop acting like savages and start resembling a reasonable human being. A reasonable person does not require an explanation as to why answering a call from a parent is important, they just answer it because they are reasonable and civilized and know automatically that answering such a call is the right thing to do in the civilized world. A reasonable person also does not require others to pander to their "preferred method of communication", they just pick up the phone and deal with whatever's on the other end.

Teenagers with phones are like hungry cavemen with shotguns. There has to be a way to pull the plug before things get out of hand and dumb stuff happens. This app is part of the solution. If a teenager's trumped up, uncivilized sense of independence is telling them to disrespect their parents and not answer their call, then this app is a useful tool for parents. The correct mode of operation, of course, is to prompt the child to call their parents so the parents can then tell the child that they're coming to pick them up immediately, and to have the phone ready to hand in because they're never going to see it again. The child should also prepare to have their wings clipped.

Unreasonable savagery can not be made civilized through reasonable discussion. That's why economic sanctions, bombs falling from airplanes, and smartphone crippling apps are still effective tools for civilized people.

Well, it sounds like it's time for someone to put on his big boy pants! Congratulations, son!

Yes, real-world software projects that make money for a business (and pay you a salary) are larger than one man can handle. There's a lot of grunt work, and maybe only a handful of new and interesting things to do. At some point, you're going to have to accept this, and just get on with it. If you work for a business, the goal is to make money, not to work on new, kewl, glamorous software projects all the time. Sometimes those goals do intersect, but it's rare. It's called 'work' for a good reason.

It also sounds like you're suffering from another common malady, and that is the idea that programming is all about writing code, and programming languages, and frameworks, and fast turnaround results. I think you're starting to realize that this is not really the case, but you can't figure out why, so you suppose that maybe it's due to the insurmountable grandioseness that seems to surround even the smallest programming project. I think you've grown up under the spell of "programming as an end in itself", and now the illusion is showing some cracks.

Look, programming is not an end in itself. It's a way to express the solution to a computational problem. Think about that for a minute, or, preferably, the next week.

Programming languages are basically the same idea as mathematical notation - it's a way to express an idea about how to solve a problem. Sure, there's also the coolness of having a machine take your expression of how to solve a problem and actually solve it for you, but programming is still just a way to express the solution to a problem.

Look at all the posts we see everyday on HN and proggit about programming languages and frameworks and whatever the latest hare-brained language idea that the functional programming circle jerk fest has come up with. Man, it's like going to a math conference and all everyone talks about is the latest ways to write down algebra! It's no wonder that there've been no real fundamental advancements in computer science in the last 30 years.

I think you need to rewire your brain about the philosophy of programming, what it is, what it's for, and what it's not. You are at a crucial point where you need to decide if you're ready to go up an abstraction layer, and start thinking more deeply about the various problems whose solutions may be expressible in a computation form, and stop worrying about programming languages, frameworks, and "impact". If you don't want to do that, then you might as well just be happy laying bricks and comparing trowels, and leave the hard thinking to more interested and capable people.

It was foolish because I worked at a large company, and team leads were basically impotent eunuchs who ran errands for the higher ups. I also worked in a department that had pathological ideas on how long developers ought to work (including weekends), and how short product schedules should be (unfeasibly short).

There were some benefits. I loved being able to help the guys on my team. I did my best to promote their achievements, and argue for them at project schedule meetings. I was very happy to get one of my guys a really good placement on the "technical career path" system when it reared its ugly head at the company.

Ultimately, my strengths are in technical problem solving, not in managing the psychopaths who seem to ascend to the upper echelons of large companies.

I was in a similar situation once. Here's the algorithm I came up with to get myself out:

1. Figure out what you want to do.

This is the most important step. You currently have a job, so you have time to really think about this and figure out a solid answer. The answer doesn't have to be an emotional epiphany where you find your so-called "passion", but it has to be a concrete goal. For me, it was more of a recovery of the idea that I wanted to apply my programming and computer science skills to interesting and difficult real-world problems. With that in mind, I looked at the place I was currently working at, and saw that I wasn't going to be able to achieve my goal there. So, I looked around and found another opportunity that was more along the lines of what I wanted to work on.

2. Figure out what skills you need to pursue your goal.

So, when I found the new job that I wanted, I interviewed for it, and got rejected. I asked for feedback, and I was told that my data structures and algorithms knowledge wasn't good enough. I suppose if I had followed my own advice, I'd have realized this before I applied. After stagnating at my old job, and foolishly taking a team lead position, my skills had certainly atrophied. However, the interview failure was exactly the kind of real feedback/wake up call that I needed.

3. Work on improving your skills so that you are ready to actively pursue your goal.

After failing the interview, and getting some feedback, I set to work rebuilding my data structures and algorithms knowledge. I bought a copy of Cormen, et al., and brought it everywhere. At work, I would go off and hide somewhere for an hour a day, and study some part of the textbook. At home, I worked on a core data structures and algorithms library in C. I'd get up an hour before work, and write unit tests or fix bugs. I'd use the evening to hack on new code for the library. I was pretty exhausted after work, and I had three kids, one of whom was only a few months old, but I pushed myself ahead because I had a goal, and I didn't want to be stuck in my current job any more.

4. Don't give up in the face of failure. Keep the dream alive.

After 5 months of study, and writing the data structures and algorithms library, I decided it was time to apply again for the new job I really wanted. I explained in a cover letter what I had done since the first interview rejection to address the feedback I'd received, why I really wanted to work at the company, and how I thought it lined up with my career goals. Within a week, I had heard back from the company, and scheduled another interview with them. Three weeks later, it was my first day on the job!

It was terrifying to apply for a second time. I had no backup plan. My current job at the time was starting to suck more, and I wasn't enjoying being a team lead, so something was going to have to change, one way or another. My life at home was exhausting, too, with the new baby and two other kids knocking around. But my wife was on board with my whole plan, and tried to give me the time to do the work I needed. It helped that we had friends and family who were struggling to find jobs - there's nothing like seeing other people hurting to give you a realistic perspective on your own life, what you have, and where your life should be going.

On the other side of all this, I've made it my mission to be continuously studying, cramming it in wherever and whenever I can. I never want to be back in that hole of skills atrophy. Also, at the start of every year, I make an assessment of where I'm at goal-wise, and I make a study plan for the year, including a substantial project to work on in my spare time that will help me get to where I think I need to be. Resist the urge to hop from one thing to the next. Focus on something, and master it before moving on to something else.

Good luck!

Yes, that is <i>another</i> issue with model checkers. Either way, your original comment is still nonsense.

If you have used a model checker, you probably don't have a proof either. You have a model that might not be accurate, and testing all its inputs may be combinatorially prohibitive.