Lawrence Kesteloot

My comment was talking about a stronger kind of consistency, maybe "inevitability" would be a better word for it. You could make many different tiny changes to the rules of C and still end up with a workable programming language. (Many people have done that, there are tons of languages derived from C.) You could say that the rules of C are "random" - after learning the first n rules, you cannot use logic to predict the n+1st. So learning the rules of C is more about memorization than logic. Math is different: when you learn a piece of math, you know exactly how it follows logically from the pieces you learned before, and you know it couldn't be any other way. That's why it feels more reasonable to me to inquire about math, rather than the details of C.

Lawrence Kesteloot said it well at http://www.teamten.com/lawrence/writings/what_interests_me.html:

On a planet far away they have universities. In those universities they have many of the same subjects we teach here, such as math, biology, philosophy, history, computer science, psychology, and literature. But although the subjects of the classes are the same, the contents are different. They teach a history class, but their history is different from ours. So are their biology and literature. I’m not interested in subjects where their content is different from ours.

In some classes, though, the content is the same. They’re teaching the same physics class (assuming they’re at the same level of understanding we’re at) and the…

This has prompted some unexpected reflection. If I may, I have a somewhat orthogonal (tangentially related), slightly soapbox-y, philosophical question about the meaning of meaningfulness, which may not make any sense (recommendations for good sanitariums accepted).

The GIF of this shows

C:\>dsl
Starting DOS subsystem for Linux, please wait... ok

C:\>_

and this immediately got me headscratching about the mechanics of how this was done. My first serious consideration (after noticing the Building section and hastily discarding notions of "remote/out-of-band terminal I/O...?") was that it was somehow boxing Linux up into a TSR and then somehow running that in the background. Coool.

But no; the custom init.c uses virtual 8086 (vm86) mode to call back into DOS, trapping on a specific interrupt to enable DOS<->Linux communication. The launcher loads Linux into memory and jumps into it just like a bootloader would, then the init program maps the first 1MB of RAM (to cover all 640K of conventional memory) and hands the whole DOS address space area to vm86(2) to continue within DOS where everything left off. So, this isn't a TSR in the literal sense (it doesn't exit using INT 27h, "Terminate and stay resident"), nor in the figurative sense, wherein the program encapsulates Linux and then returns to DOS (which certain interpretations of the program output might suggest) in the same way exiting Netware or Windows 9x ("reboot in DOS mode", in certain circumstances) would.…

It’s superficially easy to bike-shed on use of clever code and debugging, but there is an interesting and fundamentally difficult question to answer underneath about what to spend your limited time learning, and how to think about it.

Yes Kernighan was trying to pass along advice to future programmers about what he thinks is how to reduce unnecessary effort, and yes at the same time spending time debugging difficult code often/ideally increases your skill and avoiding that effort might mean you miss out on developing those skills. Both things are true, so how does one decide which way to go? Of course it depends on your goals, but it’s also worth asking what the opportunity cost is. What if instead of doing battle with complexity and debuggers, you could instead pick up different skills?

It is possible that people should deliberately ignore Kernighan’s advice, and use clever code in order to gain the skills and experience needed to see that Kernighan was right. ;) It’s also possible that spending that valuable time learning how to scale to larger systems would pay off. Or, for some people, spending less time coding and more time devoted to other pursuits.

The ‘stopped evolving’ comment seems like it might be designed to stir the pot, but the best programmers I’ve ever known tend to work hard at reducing complexity by thinking hard about dependencies and about how to write large systems. They don’t necessarily shy away from high performance tricks or hard problems. It’s…

Full disclosure: I have been around a while and have written in more languages than I care to even share at the moment. Right now my go to is Ruby with Rails. However, since you say you are a junior level engineer with Java experience, why not stick with Java? Recently there was a great article on HN about using Java for Everything and it made some very good and logical arguments for going with Java. [1][2]

We see questions like this on HN quite often. When starting a new project that you would like to support yourself on, you must ask "Would I like to make a successful SaaS product?" or "Would I like to learn a new language/framework/ecosystem?". I am sure some would argue that the language/framework/ecosystem can really make or break a web application. However, there are successful business built on just about all of them:

Stackoverflow - .Net

Facebook - PHP

Amazon - Java

Bloomberg - Ruby (could have said Twitter until recently they are migrating to Java, interesting?)

Reddit - Python

DuckDuckGo - Perl

Orbitz - Lisp

OkCupid - C++

Of course many of these organizations use a number of languages and frameworks. The point is, when they started they used what they knew and went with it. My suggestion, start building! Then someday I can use your super successful application in a list like this!

[1] https://news.ycombinator.com/item?id=8677556
[2] http://www.teamten.com/lawrence/writings/java-for-everything.html

Oh absolutely... and that's a great analogy for the more computer oriented, "Reflections on Trusting Trust" highlights how it can be the supporting infrastructure of replication that passes on the relevant information... a compiler attack like that is equivalent to things like epigenetic information transfer... and for fun bonus measure since it came to mind... the short story Coding Machines goes well for really helping to never forget the idea behind "Reflections on Trusting Trust" https://www.teamten.com/lawrence/writings/coding-machines/

It definitely would be minimised data transfer, be it via an epigenetic nudge that just happens to work by sheer dumb luck because of some other existing mechanism or a sophisticated DNA driven growth of some very specific part of the mammalian connectome that we do not yet understand because we've barely got the full connectome maps of worms and insects, mammals are a mile away at the moment... no matter the mechanism evolution will have optimised it pretty heavily for simply information robustness reasons, fragile genetic/reproductive information transfer mistakes that work, break and get optimised out in favour of the more robust ones that don't break and more reliably pass on their advantage.

Scala allows you to restrict yourself to a much greater extent than many other languages. You could say use assembly for everything - there's nothing that assembly can't do, so in a sense assembly is more powerful than any other language.

For me the reasons I use Scala rather than Java/Python/etc. are the same reasons I would use Java/Python/etc. rather than assembly. To write code with the same guarantees as the core of my system would be theoretically possible in a "simpler" language, but it would be incredibly verbose: it would take longer to write and be much harder to maintain (because you'd have to keep a lot more in your head to understand each piece of functionality). If I weakened the guarantees (i.e. didn't keep track of as many possible side effects) I'd have a higher defect rate, especially when refactoring.

That's the small heart of a few projects, but I see a lot of merit in using the same language for your whole codebase: http://www.teamten.com/lawrence/writings/java-for-everything.html . And Scala is actually a pretty nice language for one-off throwaway scripts where you don't care about tracking any effects or similar as well.