News for hackers. Stuff that matters.

random_guy1234

Ask HN: How do you know “you know”?

I was recently working on a complex software project which involves multiple sub projects and they interact with each other.I was to asked to come up with the new feature which involves all these sub projects. Being so complex, I was not sure whether I know all of the pieces to make the right design for the feature. I succeeded easily.From that perspective, how do you guys know that you know...

( Read More... | no comments | 2 points | on HN )
Re:All Programming Languages are Wrong (2018) on Wednesday February 12, 2020 @04:49AM (#22307437)
> But of course, there are

Your statements are contradictory.

> they might one day actually become faster

faster compared to C/C++ ? Of course, Performance is improving day by day. What's the point?

Re:All Programming Languages are Wrong (2018) on Wednesday February 12, 2020 @03:15AM (#22306912)
Yes, there are so many things to consider. Another would be size of the binary..

Different kinds of problems are solved by different languages. Simply rejecting them without stating the details doesn't fly!

Re:All Programming Languages are Wrong (2018) on Wednesday February 12, 2020 @01:57AM (#22306535)
> Most current-day programming languages seem to be based on the idea that computation is slow, so the user and the compiler must work hard to minimize the number of instructions executed.

Instructions executed is not the only metric to consider! It doesn't makes sense to have loads and stores in the program with all of them having a cache miss.

Does the author mean that the memory hasn't caught up with the computation here? I don't think so.

> For example, one cache miss might take as much time as a hundred add instructions.

This is why compiler must work hard!

> Today's languages contain far too many features that do almost the same thing but have slightly different performance characteristics, for example regular and virtual functions in C++. This just encourages programmers to waste time on micro-optimization when they could instead invest time understanding the large-scale behavior of their program and optimizing that.

Not all programs need to worry about insane performance. But most do. It is totally upto the developers to choose the features of the language which they need. Choosing the right features/language for the right kind of programs is an important skill. Efficient code generation for all possible hardwares and all possible workloads with a restricted language features is not going to work or else Python would have been one of the very few languages to survive. Elon Musk wouldn't have tweeted that he needs C/C++ engineers ;-)

It seems the article suggests that neither the hard working compiler nor the hardware friendly language is required to get good performance!

I think these are your options:

1. You do not care about the company (Looks like this is not the case here): a. You have no emotion towards the company and your work doesn't get affected for the foreseeable future. b. You have no interest in the area and want to stay away from it.

2. Educate them how to do it right (You love the current company): You are in the company for long time and/or you know the people will take it in right spirit! a. It is possible to convince the managers! b. "dedicated colleagues" might be of help here.

3. Say goodbye: a. You see that they are doing it in the wrong way. Managers won't / dint consider your opinion. b. Your career gets affected by it.

4. They might be right: a. They might be right either technically or to get some funds. Finding out which one might be useful.

Unless you have more details to share about the company, I think you are the best judge which path to choose.

Overall, I feel it is not worth putting effort in educating them unless you know its taken positively and your growth in the company isn't affected. In other words, do you feel it is "worth investing your life" for? There is always a new company where you could be more happy about your career is what I feel!