Edit: grammar

HN is a great community, but it has a very narrow perspective on the world.

As a beginner it is fine to chose to master one language first, but in the long run you should not "choose a language", but rater learn to learn any language, and understand they all have their strength and weaknesses.

But there are so many choices of tools and technology in this industry and it is impossible to learn it all. Tribalism makes the world simpler because it narrows your perspective.

I work on mainframes and dislike Java. Conservatism is not a problem, my problem is I perceive lot of Java people being pretty smug, and they are just because Java is #1. (And I also worked in C#, so I know the difference. Java itself is not the thing that makes people smug about it, it's the position on the popularity ladder.)

I mean, if your approach is, we use this old and tested language, it has many warts, but works for us.. good.

If you go, well, we use this language, because it's #1, and therefore it's clearly the best in the world.. no, thanks. I know Forth and Lisp and Haskell, and I know the world out there, which you don't, so I know for a fact there are innovations that didn't make it to Java yet, or pretty badly.

To me, humility in programming is (partly) don't think your tool is the best just because it's the most popular one at the moment.

Finally, this perception of Java is changing (it is being slowly dethroned by Python and JS and other contenders), and with that will come more pragmatism (less of crazy OOP and patterns cargo cults), which will actually make it more likable in the future.

The more esoteric a language is, I find the more _passion_ the average developer has for that language, it's libraries, and tooling.

Now I'm not saying the passionate Java and/or C# devs don't exist - they certainly do, C# is my bread-and-butter and I like to think I still have a flicker of passion for my work - only that there is a vast ocean of driftwood developers making it more difficult to find the sharks.

Haskell (my perception of), for example, has demonstrated some of the strongest devoted (to themselves _and_ Haskell) developers I'm yet to meet. That market is just nothing but developers who love their toolset and just want to write and learn amazing code.

The risk with this type of developer is they often prioritize their toolset and amazing code over the actual businesses needs. I’ve seen it lead to the wrong tool being used for the job.

A couple years later when these devs move on the business has a harder time maintaining the code they leave behind.

There are always drifters to be hired, which has some value.

But I'll take hiring (and the implied difficulty in finding) a dozen of those kind of Devs over drifters all the same.

If they weren't passionate, why use an esoteric language? If you want an easy time, something mainstream will be easier. It isn't like anything is actually impossible to implement in C; there are just trade offs in number of bugs and time to implement. Both of which are minor impediments vs algorithm and program architecture. Anything newer than C is just bonus modern features.

Because it is kitsch. Ruby suffered this fate in the mid 00s IMHO. It gained a lot of traction because of Rails and suddenly the recruitment space is flooded with hacks and bootcampers.

All programming languages are garbage to me now. Even my favorite languages. Most systems, networks, databases, are garbage to me. Frameworks, architectures, patterns, paradigms, protocols, standards, conventions..... all garbage.

I now see the whole system as like a municipal waste treatment plant. If we work really hard, the highest thing we can aspire to is to prevent waves of unprocessed shit from exploding out a release valve into a nearby stream. Our work should be unglamorous and practical, because ultimately someone's going to have to drink our water, and making sure it doesn't have shit in it should be our highest priority.

I totally agree.

I also agree that the disputes about language choices is tribalisitic. There's nothing wrong in principle with Java. But Java nuts do love creating factory-factory-factories. Layer upon layer of abstractions really doesn't confer simplicity.

Most recently, I've been a PHP developer. It's objectively an awful language, that has grown by accretion, and was never designed. But it's quick to write, reasonably easy to read, and there's pretty good documentation online, and a million tons of chunks of example code.

So my choice of language is essentially tribal; the details of the language aren't really important, as long as it's not getting in the way. It's the kinds of people that use the language that matters to me.

Java's reputation as a corporate language is well-deserved; and (with exceptions) the type of people that use it seem to be corporate drones, that don't mind spending a week writing a factory-factory-factory that nobody needs.

Java as a language does have problems, but if you use it right, it can be pretty nice to work with. The verbosity issue is kind of a double edged sword, on the one hand there's lots of typing, on the other hand, I find it (the verbosity) can help make code very readable and easy to understand, at least if well written.

The common factor is developers lacking humility and comforting themselves with Tribal Tool-ism.

The tools are not the issue - the attitude around them is.

It's more of an anthropological and political problem than a technological issue.

Of course there is no one ultimate definitive best language, and there may not even be a definitive ultimate best language for specific kinds of problems.

But the anthropology around Tool-ism is fascinating, and under-researched.

And it's very relevant to the real-world effectiveness of CS, because irrational professional beliefs in both tooling and management can have very harmful and expensive real-world consequences.

HN feels like white collar GPT-3. It predictably likes things that are more abstract, less practical, and promise novelty while replacing the incumbent. It also used to be a very self-serving chamber for startup investors. Honestly I come for the randomness but as community it's really the point of view of vocal people only.

While I'm critical, I'm guilty of this. Well said.

I'm very much into encouraging folks to connect at a "human" level, and not treat each other as abstractions.

I also like practicality and experience. I've found that I feel as if I'm contributing, by telling stories. I'm of "a certain age," so I have a lot of them; including embarrassing ones.

    "Good judgment comes from experience. Experience comes from bad judgment."
    --Attributed to Nasrudin, but I read it from Will Rogers

I have become a bit despairing of what has happened to the culture of the tech industry. I feel as if what used to be a fun, exploratory place has become a voracious, hyper-competitive gladiatorial arena; complete with lords on the sidelines, giving thumbs up and thumbs down.

I know that it seems as if I may be looking back with rose-colored glasses, to those that have always known the industry as it is now, but I assure you. It was once quite different. We had fun, and we shared information, and we were pretty damn nerdy.

When I was reading the various accolades about Dan Kaminsky, it actually choked me up. He was the type of person that seemed to be everywhere. The people who were really good at stuff didn't use it as a hammer to pound others; they shared their passion and exuberance.

I try, in a rather awkward way, to do that, myself. I'm quite capable of being a super-negative "black hole," but I won't do that. I wouldn't want to live in a world like that, so I won't contribute it.

Being negative is an easy way to get lots of clicks and shares, but it fouls everything it touches.

Don't you say? Isn't everybody out there writing rust on neovim?

Exactly. But what I found is that refactoring java-monoliths can be a very interesting and intellectually stimulating task.

Apart from the juvenility of social memia, there is the fact that programming languages are themselves buggy, opinionated expressions of how to solve a problem. Given enough followers, some languages become very like a temple that sees no ill within its own walls.

A programmer must be able to reason clearly about the code, or something (or some opinion) has become dogma.

There are many good programming languages. Leaving tribe and tribalism brings maturity.

JVM and CLR runtimes have an enormous amount of production experience baked into them. BEAM also would be fine.

It's a toolbox with tools that are better suited for some jobs than others, and it also depends which ones a group of developers know.

Yet HN commenters tend to like the React ecosystem, which at this point is pretty close to Web Development Enterprise Edition.

It's one of the few languages out there capable of producing a codebase that lasts for so long. That annoying verbosity and enforcement of naming conventions and directory structure mean that the Next Guy (or Gal) to come into the project and probably figure out what's going on. Most codebases written in other languages are constantly rewritten in the language de jure.

"by law" -> "of the day", "current"

Exactly. Languages come and go. But if you understand the fundamentals - why things work the way they do - it makes it much easier to move between languages, programming models and whatever the latest fad is. Being adaptable is a far more valuable skill over time. Nope, it's not easy - but rarely are things of value easy (it's why they are valuable - ha!). It is easier to start out early with this perspective and continually building on it throughout your carrier than trying to pick it up mid stream later on in life, so the sooner you start the better! I've never considered myself "done" when it comes to reading or learning. Like those sharks that die if they stop swimming - that's a good way to envision your long term intellectual health :)

Creativity and cleverness is a double-edged sword, which is exactly what Dijkstra is talking about.

Distaste for Java isn't elitism or arrogance, it's just that the language is so damn painful to write.

If you start your career with Java (as I did), dipping your toe into another[0] language for the first time feels like Neo being ejected from the matrix and waking up to reality.

You realize your eyes are finally open, you're awake, and you can see that all that pain was just what Java saddles you with, and wasn't "the way programming is done (TM)".

[0] depends on which language, of course. Java to C# isn't a big jump.

I started working in C++, moved to Java, used several other languages commercially (Python, JS, PHP, Groovy, Kotlin), and about dozen other languages for personal projects including the hip ones like Clojure, Prolog, Ruby.

My first programming languages were C64 BASIC and Turbo Pascal. I've written some Ada and SML.

And I just don't understand the Java hate.

Pain points:

* Stack traces seem to run to 500+ lines and nobody reads them.

* The processes, release management, and integration of code in a Java environment is glacial slow and obtuse featuring very low automation and many large teams of dev ops. The very idea continuous deployment is absent. Code releases occur at regular intervals quarterly or monthly if you are super fast and it feels like moving a continent. All of that slowness and super man power also applies to everything else not written in Java like riding on the back of a retardant elephant.

* Java applications running enterprise web servers are monolith beasts like the Great Wall of China wrapping the Pacific. Refactoring in those applications feels like inventing a new language while sinking in quicksand. Writing a JavaScript application in a massive MVC framework feels like that too but Java is orders of magnitude worse.

* What I really don’t understand is that Java is such a fast language but large enterprise web server applications written in Java always feel so slow in user experience in production. It just feels like something from the late 90s. That slow becomes the baseline experience to internal development by which all user experience ultimately suffers. There is no reason pages from these servers should take 5-20 seconds to fully load in the browser even though the page is a light smattering of static text with sprinkles of CSS and JS. I have an application in TypeScript that emulates the front half of an operating system and it fully loads in the browser in 0.3-0.8 seconds (averaging around 0.65 seconds).

My personal suspicion is that the programming style used in Java (OOP and patterns) together with the fact that everything is a reference, and everything is implemented in Java itself way down, kills the cache locality, which is the thing that makes modern computers fast.

Yes, you can write fast Java programs, if you keep abstractions to a minimum, use arrays rather than objects when allocating, and take advantage of the JIT compiler. But these are more lab conditions (which are great for benchmarks) rather than the real world conditions. I think finally having a proper record type in Java will help to fix this.

Other programming languages make it "more inconvenient" to apply such managament/programming practices.

ok, you have a point here :) when you have libraries for filtering stacktraces you know something is wrong

> the processes, release management, and integration of code in a Java environment is glacial slow and obtuse featuring very low automation and many large teams of dev ops. The very idea continuous deployment is absent

that is the exact opposite of my experience - maven infrastructure beats anything C++ or Python have, and in every Java project I worked on we had CI (mostly BitBucket+Jenkins but I've also seen Apache Continuum and Team City and we had CI even back in svn/cvs era).

> large enterprise web server applications written in Java always feel so slow in user experience in production

Also not my experience, I've worked on an intranet app for warehouses that used jboss 4, jbpm 3 and plsql at the backend and a very small custom c# client running on remote Windows CE terminals. We had transactional and persistent business processes drawn as graphs invoking PL/SQL on the server, it was pretty nice. And the full roundtrip between pressing a key on a remote terminal and rendering the received response was under 150 ms. That's for all the layers: - c# client -> intranet -> SOAP on jboss -> EJB3 -> jbpm -> hibernate -> JDBC -> PL/SQL and back

And it was around 2008 - in the age of spinning disks :) Certainly it was good enough for us and actually faster than previous simple code that we were replacing (remotes telnetted to a C++ text-only server that connected to the same business logic in PL/SQL). ORM cache wins covered all the performance loses caused by additional abstraction layers.

We didn't use html/js/front-end templating engines tho, at the time most people used JSF or similar and it sucked. We had a custom XML protocol that was rendered by the C# client and it was very fast.

Of course it wasn't that demanding - under 500 users all on the same local network. But without any thought spent on optimization (other than enabling 2nd level cache in hibernate) it was a pretty good result.

> There is no reason pages from these servers should take 5-20 seconds to fully load in the browser even though the page is a light smattering of static text with sprinkles of CSS and JS.

well yeah, something's wrong. I bet on data layer or passing each request through 20 microservices on different continents (this is the most recent fashion in server-side programming and it sucks).

Mind you, I'm only saying that after having spent 2 years in Kotlin. The Stockholm syndrom is real: you don't realize how much better things can be from the inside. Programming has become enjoyable again, my work 'feels' cleaner, more readable. Null safety makes reasoning about code that much easier. I can switch to functional programming when it's convenient. I keep all the tooling from Java, including the amazing IntelliJ IDE.

At the end of the day, choices are a matter of arbitration. Do I want the speed of C, the ecosystem and resource pool of Java, the locality / mathematical guarantees of functional languages, and the IntelliJ IDE? Sure. But they don't exist in one language.

So when I'm programming embedded, it's C. When I'm creating a complex data treatment pipeline for machine learning, it's Scala. And when I'm making a CRUD application that will have to support a team of 15 developers hacking on it for a decade, I'll go with Kotlin.

I don't take issue with your comment overall, but this is not true. You can catch exceptions within lambdas, and you can define functional interfaces that declare that they throw checked exceptions.

My issue is that for something as everyday as "throwing exceptions", you have to define a separate interface, or catch it inside the lambda. The first option being the Evil Verbosity everyone is on about, the second essentially rendering the exception useless as an instrument.

[1] : https://stackoverflow.com/questions/18198176/java-8-lambda-f...

Inversion of control, interfaces, and OO make wandering a codebase feel like being lost in a bureaucracy.

Then we het to the issue of projects being coupled to IDEs. "Oh, this is an Eclipse project." "Oh, this is IntelliJ".

All of that chrome and tailfin leads to projects that take longer to boot than the OS.

The disdain for Java may be less about the language per se than the attendant mindset.

We use Maven projects, and edit them in whatever people prefer to use.

This would not be such a complaint (look at the explosion of build systems everywhere) if Java were less touted as "write once, run anywhere".

Build systems and configuration management are two hard problems.

And ant is prehistory.

In C++ they don't even have Maven equivalent (only thousands build systems but no universal way of naming/deploying/running projects or specifying dependencies).

In Python there's several maven-like systems that are incompatible and don't have the concept of universal project identifier or repositories.

In JS and Rust they basically copied the Maven system and changed it a little.

Clojure uses Maven wrappers with lispy syntax for pom files.

I struggle to find a language where this is solved better than in Java.

With that in mind, though, the biggest gripe I have, by far, is its needless verbosity. It always feels like I need a huge amount of boilerplate and repeated keystrokes to get things done. My fingers literally get more sore writing Java than anything other language.

Lack of extension methods is probably my next complaint, because you end up fumbling about writing a lot of code to address what should be

Lack of null-safety would be the next one, too. I'd say around 90% of my runtime errors are due to improper null handling, so this would cut down a huge source of errors.

On par would be painful deployment (and to a degree, package management). For some reason Java always felt like it needed an industrial-size team to get anything actually up and running, and needed more hardware than any other language. That might not be fair, but I think it's definitely fair to say that deployment is not Java's strong point.

This is my biggest complaint about OOP development in general and languages like Java and C# that are heavily invested in OOP paradigms are miserable for me as a result.

It doesn't, in fact; but configuring a Java application to run well with minimal resources is a problem that isn't a programming problem, it requires a separate skillset. So you end up with build specialists, and deployment specialists, which in turn results in long deployment timetables.

And then you have to deploy certificates against all that.

I'm not bitter.

Or until you realize that you have a 99th percentile latency of multiple seconds...

I guess enabling your users to do that might be work for a sysadmin, but that's more a reflection of those users having higher expectations for Java than for other runtimes - providing your users with the same capability in other stacks is never easier than Java, and often significantly harder.

The first one is annoying, not really something a professional software developer would care about for more than 10 minutes while creating a new product.

Macros can be major footguns, they're something that can only be realistically used efficiently and safely in large code bases by actual senior engineers. So the jury's still out how much they really increase productivity for the averaged developer.

Higher kinded types seem great, but it seems that they're not easy to implement and they also slow compilation down a bunch (someone please correct me on this). These seems hard to bolt on to an existing language, so Java can't be faulted much.

There's a place for "artistic licence languages" like Ruby or Clojure and I like them for experimenting, but when you want to build a house you want the bricks to be boring.

I find that the language itself is quite good, simple to use and has some nice features and performance... but the issues you mention are also there, however they're part of the frameworks and individual codebases.

Did the Java community get over their love of code generation already? Last time I used it, I'd debug the crazy 1000's of computer generated lines that people changed here and there.

Anyway, that is great news. That unexplainable love for code generation was one of the things holding the language back. It's always good to see things improve.

Just as Go.

You say that like it's a bad thing...

I mean, plenty of arguments used in those wars are perfectly reasonable. PHP isn't elegant. Java is verbose. C++ is overcomplicated beyond salvation. JavaScript is shit. Those are all facts ;) However, they still can and often are the best choices for a given project. Is PHP pleasant to write in and think about? Heck no, but deploying it is exceptionally easy and sometimes that's much more important. I wouldn't ever think of using JavaScript as an example of good language design, but it accidentally turned out to be flexible enough to become the lingua franca of the Web and is here to stay. No amount of drooling over Rust will change the fact that you're going to have a hard time with it on some platforms where having a proper C++ toolchain available is ubiquitous. And sometimes the way Java code use to be structured is exactly the perfect fit for a project you're working on to ensure its long-term maintainability despite of the fact that people who work on it come and go in your startup all the time (so having access to a healthy pool of Java developers to hire from who's pretty much already familiar with your project despite of never seeing it before is a huge advantage).

If those tools really were "suboptimal" they wouldn't exist anymore. They do, because they aren't - if anything, they may be poorly chosen to do a specific job.

I agree with everything you said.

> If those tools really were "suboptimal" they wouldn't exist anymore

A tool (such as a language) can certainly be suboptimal on its own but still be productive because of the package of the language, the ecosystem, the knowledge that people have etc.

My point is, even if Java would offer the best package, it is still valid to criticise the shortcomings of the language and dislike this part of the package. It doesn't have to be "hate because of enterprise".

> Java is disliked on HN because it represent "enterprise"

which I think is not true. Maybe for some people, but there is valid criticism too.

I am happy to give examples, but I am disappointed that you call my response "tribalism". It really is not meant like that.

Sure, it's not as fast to add stuff as C#, and also surely anyone looking for a fight can nitpick, but it has most modern features you'd expect a modern language to have.

Also the JVM is highly optimized, more stable and faster than most other runtimes (and it can run must of the other languages).

This probably describes 99% of all programming done today, no matter the language.

Not everyone is a polyglot programmer able to choose their tech stack at their company.

It's kind of like with assembling a tricky 1000-piece jigsaw puzzle. You assemble the frame first (like everyone always does), and wonder how to fill it in. You could pick the most obvious feature on the reference picture, start there and focus on expanding it piece by piece until the picture is done. But what I imagine most people do is first speculatively placing all the pieces that seem trivial to match to corresponding picture features, in order to reduce the number of unplaced pieces quickly, and give themselves lots of starting points to expand their solution in parallel. This approach is useful despite it commonly turning out later that some of such early starting points are placed completely wrong - puzzle blobs get easier to position correctly once they grow in size.

It's a long way of saying, if you keep track of confidence levels of your beliefs, instead of taking everything you read on the Internet as certain, even off-hand remarks on HN can be useful in navigating the enormous space of technologies and philosophies that form the software industry.

If you are building a bulk file rename tool, it doesn't matter how you do it as long as it works. If you are handling untrusted data from remote sources, then you may want to consider if C is a good idea.

Edit: added an example

All the city engineers were perfectly happy with it, but the developers behind it were worried that ASP web forms were becoming obsolete. Not really an illegitimate concern I supposed, but what they did was hire a company to rebuild it in AngularJS.

So now they have a technology nobody else uses around here, while web forms simply turtles on because of how much legacy it has in various places that aren’t upgrading it.

As a TA I see a lot of people who also made these same decisions, maybe just add Arch Linux and zsh to complete the cliche. So you don't have tl worry, as this is actually relativly commom.

But I don't think it is wrong to have intuitions based on stories, as long as these don't prevent you from trying out said tools or languaged yourself. They can be right, but they might also be outdated. Just stay curious.

And yet, after many years, as I've finally stabilized on a set of tools and workflows I feel really works for me, it happens to include Vim and Zsh. Of all the programming languages I've used the one I've enjoyed the most is indeed Rust. I have even come to really enjoy Unity after ending up at a company which uses it.

It's a bit different from other tools and if it's not your cup of tea that's perfectly understandable. But why would you torture yourself like that if you're not willing to give it a fair chance?

Edit: there are of course also those who do give it a shot, do learn the Vim way™, and then conclude it's not for them. That's great, I have no problem with that.

I would argue the post is primarily about complexity, and in school you probably haven't seen how complex software can get because most projects have to be started and finished within two to three months. Once you start working, you'll quickly discover that the complexity of existing systems can be overwhelming, but this is normal.

After 3-6 months working on a complex codebase, ideally with a team to help you, you'll have some idea of how the complex system works, and even if that idea is wrong (in many, many places), it will help guide future changes to the system.

The point then, of reminding programmers to have humility, is less about hearsay on the internet and more about the need for tools and languages to make life easier for the individual programmer trying to read the code, then plan, make and deploy changes to a live system. If you're lucky, you'll feel like the system makes sense but changes too quickly. If you're unlucky, the system will make little sense and it'll be entirely your job to fix it or put up with it. Usually, hopefully, there's a middle-ground, where the system works well enough you don't have to make changes, but you're probably not entirely satisfied with it either.

Humility can also be the reminder that just because a system looks broken (to you) doesn't mean it needs fixing right this second. If you can spare the time, it's almost always better to try and understand an existing system's quirks before you set out to redesign it and end up re-implementing some of the same quirks yourself.

I'll echo mentions elsewhere in this thread and suggest John Ousterhout's A Philosophy of Software Design as a good book on the subject of complexity and API design, but to newcomers to the field, I'll leave the warning that it doesn't cover TDD as much as it could and it also doesn't cover modern Scrum/Agile practices and how development fits in with product design and company goals. But I still highly recommend it.

Usenix talks, for example, tend to cover a lot of real-world engineering-at-scale challenges. The more you hear how programmers often make mistakes, the more the lessons around humility will sink in. :)

[1]: Re. changelog, and the subject of both mistakes and TDD, https://changelog.com/gotime/174 was a great listen also. Testing has gone from niche to mainstream back to "the best projects do it, but maybe only when forced," and it's interesting to listen to modern takes on what to test and when.

I feel that if we will use a tool, we need to take the time to become proficient with it.

Here's an article that I reference fairly often. It's sort of a "reality check": https://veekaybee.github.io/2019/05/10/java8/

I have thought this for a long time.

I have reckoned that it takes me at least six months full-time to come to grips with a new programming language (I'm 65 now, I learn slower, I'm retired, and I'll be damned if I'll learn any more).

Over the years, I've worked in teams dominated by young whippersnappers who are very keen to learn the latest language/library/framework. But they don't allocate 6 months; they seem to think they can press their new tool into production after just 6 days' practice. The result was unsually unmaintainable code.

I understand the motivation of the whippersnappers; they expect to change jobs within the next 6-12 months, and they want to be able to put the latest hot shit on their CV. But we ended up with systems that only a couple of people in the team could read, let alone maintain.

Write Simple Code. Don't Be Clever.

There are however a constant demand for JAVA, C# and PHP developers. Because that’s the languages that are used in my region of the world, and as interesting as something like Rust might be, you’d have a hard time actually finding a job working with it. Even JavaScript isn’t that outspread here, if what you’re after is a full-time JavaScript job, because there is almost always a JAVA, C# or PHP backend to go along with it. You can of course find C++ job, there aren’t many, but there are some and I’m sure some of those places actually use Rust behind the scenes, but they don’t advertise it.

Anyway, I think my point is that there can be a big disconnect between HN and what you’re actually going to end up working with, and you’re likely not going to work with just one toolset for your entire career either. Before I became a manager, I spent almost a decade working mainly with .Net, but with the rise of things like Azure Services I stated working more and more with Python and Powershell, these days I almost exclusively work with Python as I’m mostly handling data for BI or management purposes and let the programming get done by my developers. We have recently picked up PHP though, which you likely wouldn’t think would happen in 2021 if you go by how dead PHP is supposed to be. Well, it so happened that there is a big open source project in my country that utilises Drupal to create a “forms generating” CMS system, that we want to be capable of building modules for, which means we needed someone to learn PHP.

Another really valuable lesson in humility I learned, and it took me years to do so, is related to the arrogance many software developers adopt when we get into the real world and start building things with the business side. Because our skill-set is so linked to dissecting and understanding problems, some of us adopt the unfortunate habit of thing we know... well everything. I’ve been arrogant enough to think I understood how our payment business process worked better than our director of payments, and of course I didn’t, but it was just so used to handling problems that I though I did. If you can, do better than me and apply your humility to everything, not just tool chains.

It's just "Java".

If your journey is anything like mine you will end up driving yourself lower and lower into the stack until you wear yourself out. Ideological buoyancy will take over and you'll float somewhere higher, but you'll be much more knowledgeable and valuable as a result. All that to say, don't be too hard on yourself.

I think that these opinions are mostly correct, but you and anyone else would learn a lot if you chose to actually try Java and PHP and experience this verbosity and inelegancy first-hand, as opposed to just hearing about it.

I see it all the time in my daily life, people are insecure and mostly want some confirmation that choices they made are good ones.

They buy a car and then they start saying that other car brands are bad or breaking so easily. They cannot face the truth if their car turns out to be a crap. Seems totally like programming language bros, and some people cannot stand that in other language they could make more money. So what? There are probably people using that language that make less then them.

I don't want to live such life, I want to make mistakes and pay for them if needed. Lots of choices are reversible or can be changed, be flexible.

I would say humility is the most important quality for an engineer to have if they want to be able to grow as an engineer. I've come across a small number of engineers that have lacked humility and acted as if they knew everything and they were a nightmare to work with. The first instinct they have when they approach most problems that they come across is that the issue can't possibly be caused by their code and you have to provide an unreasonable amount of evidence or a smoking gun to convince them to investigate their code. They design solutions as if they know the perfect way and they seem to lack empathy for users or others that may have to maintain that code.

Abandoned? 79% of websites are still running on PHP. Let's postpone the funeral.

> This made me arrogant, because I saw myself as above my classmates

As others have said, "good" and "bad" depend on the use-case; everything has pros and cons; but some things are still objectively better than others (e.g. if tool A supports more data formats than tool B, whilst being just as fast, just as secure, just as supported, etc. then A is a "Pareto improvement" over B; there is no reason to choose B for a new project).

Whilst it's common to explain why something is "bad" (e.g. PHP encourages 'stringly typed programming', which makes SQL injection and cross-site-scripting vulnerabilities more likely); it's also important to explain why such "bad" tools are nevertheless widely used. For example, PHP is widely supported by free/cheap web hosts, is easy to set up (just copy a .php file to the server) and run (the URL is the .php file's path); it runs concurrently without needing shared state/threading/etc.; it has a built-in Web framework ('$_GET', '$_POST', 'echo', etc.); it can be embedded inside HTML files; and so on. This all helped it grow a large community in the Web 2.0 days, and lead to useful applications like Wordpress and MediaWiki, whose 'plugins' got many people into programming. This community of pragmatic (but often inexperienced) developers and their ability to quickly churn out Web apps has sustained itself to today; whilst the developers have matured, applications/libraries/frameworks have grown much more complex, the demands on the language are more diverse, and the language maintainers add new features and fix some of the language's underlying problems.

I still consider PHP to be a particularly bad language, and would need an incredibly compelling reason to choose it for new project. Yet I know there are many reasons why people have chosen it, and continue to do so. Those aren't necessarily "pros" for the language, e.g. it often comes down to historical inertia and 'what we know', which is much less important for those just starting out, or working in a different field (e.g. data scientists), or facing a different context (e.g. Web apps implemented client-side, fetching data from managed cloud services).

If we see the arguments against, but don't know much of the context or reasons things still get used, it's easy to make the assumption that others made bad choices due to ignorance. I think this is similar to Chesterton's Fence https://en.wiktionary.org/wiki/Chesterton%27s_fence i.e. we should understand the reasons why someone did things in a particular way before we scoff at their poor life choices (after all, sometimes those reasons make it even more hilarious!).

Every language phasing the web is stringly typed, I have seen unproper filtering and escaping in all languages I worked professionally with.

Heh, not even close. Off the top of my head I can think of Ur/Web as an extreme example ( http://www.impredicative.com/ur ), and slightly more mainstream systems like Yesod ( https://www.yesodweb.com ). I've worked professionally with Haskell, although not for Web stuff. These days I mostly work with Scala, which has a similar typing mindset to ML/Haskell, but unfortunately inherits a lot of stringly typed legacy from Java. We use an in-house library that provides zero-cost newtypes to distinguish between different semantically-distinct data types, many of which just-so-happen to be representable as subsets of String (e.g. GET parameter names, GET parameter values, POST bodies, etc.). This makes it a type error to try and e.g. concatenate different sorts of data together.

W.r.t. "escaping", I tend to avoid it entirely since it's inherently unsafe:

- "Escaping" doesn't distinguish between its input and output types; they're both just "String", and we have to make assumptions about the contents of each (i.e. it's unsafe)

- Having the same input and output types makes it possible to "double-escape" by accident. This discourages the use of escaping, just-in-case it happens to be done elsewhere; hence it's very common to end up without any escaping taking place.

- Having the same input and output types makes escaping functionally unnecessary: anything we do to an escaped string could also be done to an unescaped string, so it's up to us to remember that it's needed (i.e. it's unsafe).

The whole idea of "escaping a string" betrays a flawed approach to the problem. Instead of throwing everything into the same representation, then manually trying to figure out whether or not a value comes from a particular subset of that representation or not, it's much easier and safer to avoid lumping them all together in the first place. If our inputs have a certain type (e.g. HTTP.Get.Val) and we can only output certain other types (e.g. JSON, Map[HTTP.Header.Key, HTTP.Header.Val], etc.), then the processing which turns input into output is forced to specify any necessary conversions. Whilst such conversions may involve escape sequences, having them associated to particular types is more akin to serialisation.

Heck, at my first PHP job we largely solved this problem not by 'filtering and escaping', but by modifying the PHP interpreter to distinguish between 'clean' and 'dirty' strings (with literals being clean, and $_GET, etc. being dirty). Operations like concatenation would propagate 'dirtiness', and output functions like 'echo' would crash if given a dirty string. Traditional 'escaping' functions would convert dirty strings to clean ones, and crash when given a clean string. Having this be dynamic was more annoying than ahead-of-time compile errors, but it still did a pretty good job.

There's pretty much no excuse for stringly typed languages/libraries/etc. when such such trivial solutions exist, other than the historical inertia of legacy systems.

It is true that some languages makes it easier to go bytestream-to-string than others, but I can do all of that in PHP by creating my own types too.

---

Web consists of bitstreams, not bytestreams. Somewhere in your pipeline you have bitstreams-to-bytestreams, if you don't do that correctly you will either have data loss, injection or xss, true for every language.

It is true that some languages makes it easier to go bitstreams-to-bytestreams than others, but I can do all of that in PHP by creating my own types too.

---

Web consists of voltage fluctuations, not bitstreams. Somewhere in your pipeline you have voltage-fluctuations-to-bitstreams, if you don't do that correctly you will either have data loss, injection or xss, true for every language.

It is true that some languages makes it easier to go voltage-fluctuations-to-bitstream than others, but I can do all of that in PHP by creating my own types too.

---

Web consists of excitations of the electromagnetic field, not voltage fluctuations. Somewhere in your pipeline you have excitations-of-the-electromagnetic-field-to-voltage-fluctuation, if you don't do that correctly you will either have data loss, injection or xss, true for every language.

It is true that some languages makes it easier to go excitations-of-the-electromagnetic-field-to-voltage-fluctuations than others, but I can do all of that in PHP by creating my own types too.

---

Web consists of entanglement of energy quanta, not excitations of the electromagnetic field. Somewhere in your pipeline you have entaglement-of-energy-quanta-to-excitations-of-the-electromagnetic-field, if you don't do that correctly you will either have data loss, injection or xss, true for every language.

It is true that some languages makes it easier to go entanglement-of-energy-quanta-to-excitations-of-the-electromagnetic-field than others, but I can do all of that in PHP by creating my own types too.

---

...

  ``I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.''

[0]: http://threevirtues.com/

https://www.oreilly.com/openbook/opensources/book/larry.html

John Osterhout wrote what may be the best elaboration of this perspective in his wonderful book "A Philosophy of Software Design."

A couple of related thoughts from an old grizzled programmer (moi ;-), gregfjohnson.com):

Rule number one: All code must follow the Porthole Principle. The fundamental issue in programming is that we each look out at the world through a mental "porthole" that limits our field of view. We are limited in how much we can see and understand at any one time. Therefore, systems must be structured so that they can be understood completely, at all levels, even though we are only allowed to investigate them piecemeal, through our own limited and finite cognitive windows.

Abstraction is the essential tool that allows us to create systems of arbitrary size and complexity. A beautifully designed abstraction is easy to understand and use. It is so trustworthy that you don't feel any need to worry about how it is implemented. Finally, and most importantly, it enables you to reason with rigor and precision about the correctness of the code you are writing that makes use of it.

They may seem obvious. But in practice, far too often do I encounter code that is far too complex, and fails your porthole principle, and extremely hard to reason about, or work in, without worrying.

Now, when such code is made by an inexperienced dev, this is fine, and acceptable: finding the right abstractions, or even seeing the need for those, comes with experience. But when senior devs produce such poorly abstracted, hard to reason, complexities, it is inexcusable. It is your task to make complex problems simple. To make unreasonable domains reasonable. To apply the right abstractions in the right places.

To make code that you can work on when tired, distracted and stressed. To build structures where a junior can feel at home in, in hours.

'The smartest code is the code that has your back in your dumbest moments and boosts your productivity in your best moments'

Heh, I don't think there are a lot of proven abstractions out there. And most so-called "abstractions" are in fact not. Let me explain using two popular abstractions, ones that are so low-key that they wouldn't even considered by most.

1) Function calling. This is an abstraction that abstracts away the logistics of setting the state in a process in the right way such that the next piece of code can continue. When that code finishes, it will leave a well-defined state as well (first, in terms of the call stack, but maybe a return value as well).

Now, I contend that function calls can be the wrong abstraction in many situations, at least more often than people think, and many many functions seen in the wild should never have been created. Functions remove a lot of control where values are stored, and the storage locations can't be shared across functions, which results in a lot of nested calls that tunnel through many of the received arguments - instead of just leaving them in a common, predefined place. Also, lots and lots of functions in practice tend to amass local state, and as it is with the tree-shaped nature of function calls, once you give up control, that state is gone, so you'd better clean up after yourself. This is in fact a great burden, and very complicated systems arise to "solve" this problem, like constructors/destructors, try/catch, functional unintelligible academic theory (Monads), and other resource tracking systems.

2) Streams. In my mind, they are arguably one of the most successful abstractions ever created. A stream abstracts one of the endpoints of a unidirectional connection (the read or write endpoint). You use it by just saying "read" or "write", and very little of the complexity of interacting with that other endpoint shines through - lossyness of the connection, flow control, packet size, error handling... streams don't provide access to most of these.

This can be a very unhappy situation to the point where the code that deals with that stream would be much better off just dealing with the underlying connection directly. A huge aspect of this is flow control and scheduling - we mostly act like transmission was an atomic operation, but there is a lot of logistics involved. To hide this, OSes invented blocking interfaces, putting your process to sleep until the operation is completed, or providing simplistic non-blocking interfaces. All of this is very bad for performance and predictability, especially blocking interfaces.

I think the "don't be clever" edict applies to code segments that are best described as "you won't believe what happens next!", and fairly so.

Reusing variables in a way that is confusing is a code smell, and rather than being "unclever", I would characterize it more as just "bad".

In my mind, an example of code that is "too clever" looks more like this:

  while (*dest++ = *src++); 

Do the programmers that people look up to as role models (Torvalds, Jonathan Blow, Guido, Ken Thompson, Rob Pike, etc.) practice humility in the code they write? I would say yes, absolutely.

Do they practice humility in the rest of the software development process? I'm not so sure it is cut-and-dry in this case.

Outside of _writing code_, the software development process often leads to situations of "what is the right path to take?" which requires some form of leadership, and clear communication about some leader's own level of confidence in a given approach. It's a communication problem, and while practicing humility in this area often "sounds good" on paper - I think it often leads to death-by-committee.

Am I wrong? Have I misinterpreted what people mean when they describe practicing humility in software development?

Being humble does not mean you are passive and agreeable. It means that you can recognise you own fallibility and stand up to admit your mistakes and accept alternatives.

I love coding in Go because of the emphasis on simplicity.

Avoiding clever tricks seems counter-intuitive, but after decades of coding, I completely agree. They give me a buzz when I write them (part of my enjoyment of coding is from finding clever solutions to problems, after all), but they always bite me in the arse later.

I like to get endorphins. I like that the field I chose as a career can give me that when I feel like I did something well. I think an argument goes into pretty vague territory if one tries to argue that it’s more “good” when you get a nice feeling from helping others instead of feeling nice from your own work.

The distinction between the "goods" I was talking about is a question of whether you're motivated by that defensiveness, or some sense of lack, or if it's an act of caring, or an act of joy, or whatever. There's a world of difference between those approaches to action.

a) pride in a job well done, which is what I believe the other commenters here are referring to, is the feeling of taking pleasure in successfully producing a well-made (something), whereas

b) pride in the sense of 'puffing oneself up' is holding and/or projecting an unrealistically high estimation of one's abilities, perhaps in an attempt to impress others - you could also refer to this as vanity

I don't see a problem with a); taking pleasure in doing quality work doesn't preclude one from seeing potential areas of improvement and it doesn't have to be pathological (telling everyone else repeatedly how good your work is, for example, which tends towards b) ), it's more like an intrinsic source of motivation and joy.

I disagree. Pridefulness stays pridefulness irregardless of the context. Whether you puff up because you did something socially rewarding or not doesn't matter.

The other side of the coin with pride is shame. A prideful person might feel pride if he helps someone, and that's nice, because he's told himself that not helping is shameful, so he just went from shame to pride.

But pride is only good in relation to shame. If he had the choice, he'd choose to be happy about helping through empathy for example, rather than pride. It's best to escape the duality of pride and shame.

I'll put it another way. Would you prefer to do something out of shame, fear, lust, pride, courage, caring, love or joy? It's not all the same, is it?

Double negative in a single word. https://en.wikipedia.org/wiki/Irregardless

Interestingly the redundancy of Java is problematic for a similar reason that the redundancy of a double negative can actually reverse the meaning.

In public to be prideful, it is at expense of others, you put you above the other, and it is fueled by the external. It is negative energy sucked from outwards.

> Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

From: https://en.wikipedia.org/wiki/The_Elements_of_Programming_St..., 2nd edition, 1978

https://news.ycombinator.com/item?id=22348386

Djikstra is all "You need to get more humility dammit! You think you don't have to listen to me and do exactly what I say because you're smart but I am smart so I /know/ you're not! Be more humble! I'm right and you are not!"

You can interpret parts of it in ways that are reasonable. We do need to be humble in any engineering endeavor is a stunning glimpse of the obvious and hardly worth an ACM Turing award lecture. His fondness for simultaneously formally proving what you program have basically very rarely if not actually never been made to work in a useful way by anyone and he falls into the trap of blaming everyone else for this practice not taking off. Everyone else is too arrogant to just do what the great man says when it doesn't work.

Humility is a thing. I've just trashed Djikstra which is obviously a thing that must be done with humility... The humility of a random, semi-anonymous internet messsage board post is probably more humble than an ACM Turing award acceptance lecture. I'm a humble person with much to be humble about.

and hence the quintessential quote

   arrogance in computer science is measured in nano-dijkstras

     - alan-kay

He wasn't particularly humble in his writings.

> The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.

The truth is really somewhere in between the two extremes.

Another thing I often say is that most of the real hard problems in software development these days are social problems. What I mean by that is that you have to account for the characteristics and limitations of not only yourself, but the users of the software, the rest of your team, and your organization as a whole, when writing code or designing systems. In other words, don't get in over your head, make it usable, document what you've done, think about the consequences of what you're about to do (and write that down), and many other things. This is inherently a humble perspective, because, if you notice, you are the smallest thing that needs to be considered in all this.

If I try to tell people that some approach x is incorrect in this particular case because of reason y, they think I must be a dinosaur because all the articles they read online indicate that approach x is popular and therefore I must be wrong and lazy... As if I had been twiddling my thumbs for the past 15 years, when in fact I've been working non-stop nights, weekends, day job, open source side projects etc...

It's infuriating. I don't know what to say. Nowadays if I encounter such junior dev, I don't even try to start to correct them. Nothing can be done. We have reached peak intellect and things are going down. People will simply get dumber, unsophisticated black-and-white thinking will become more pervasive and I need to learn to live with that; sit quietly in meetings, smile, nod and cash my paycheck.

Humility is accepting you can be wrong, or what you do is suboptimal, etc.

Being submissive is conceding arguments even if you know you are right and you can prove it.

Companies are not democracies. Companies claim to be meritocracies but are not. Companies are ultimately governed by authority. Authority defines what is truth and what is not: authoritative truth.

Each authoritative truth is a fork from reality, and is in a way, a form of fiction.

Authoritative truth can go against logic, applied science, empirical evidence, common sense, ethics and morality. It does not have to be correct, authority makes it correct.

Because of this, engineering and authority are completely opposite things.

An authority with humility will try to lead the team towards understanding things from first principles. An authority without humility will be creating and expanding on authoritative truth.

And expertise can be incredibly narrow- when dealing with complex systems and interrelationships between such systems, it’s really easy to accidentally encounter problems that you might not have expertise in; in fact you might not even be prepared to even recognize that you’re out of your depth.

If you like this post, you might also like reading the relatively short book, A Philosophy of Software Design by John Ousterhout, or the talk you'll find on YouTube by the same name, which covers roughly half the topics in the book.

Non knowing my limitations was essential for me as well. When I was a kid I saw a world full of possibilities and I could do much better than anybody else.

It was not that easy, it was painful and I needed help for getting things done. But if I had not been the arrogant bastard I was I would have never started the things that later finished for pride. I would also had not improved my skills in the way that I did because I had to give what I promised.

https://medium.com/@acidflask/this-guys-arrogance-takes-your...

This mostly seems to be two stuck-up academics caught up in sniping (very cordially) at each other over petty academic crap.

EDIT: Okay, I've read EWD692 and I get why Backus was pissed now. This still feels a lot milder than people are suggesting.

Doesn't take away from the validity of his points, but it made me chuckle a bit.

It is about understanding how well we can reason about code, not about how humble we must present ourselves.

The fact many commenters here talk about the social humility, makes me believe many hn readers have read the article (let alone the therein linked articles) poorly or not at all.

Dijkstra's advice/definition of humility was that we should be aware of our own limitations when programming. That is both a "technical" as well as "social" construct, for example to be aware of your own technical limitations is incompatible with saying "I am the best programmer in the world", or "I understand the most complex code", because it demonstrates an unawareness of your technical limitations IMO.

However, my observation was largely a unrelated anecdote on the wording and not a critique of the author or the message.

Furthermore, I notice in clinical healthcare and software engineering that ego tends to be inversely proportional to capabilities because the jerk reaches hubris by stopping learning and assuming they're always right, leading to less knowledge, career development, feedback, and authentic peer interactions. Eventually, they become the "I've been doing this for X years" people. They become infinitely awesome, but in their own minds only.

For example, is Go a great language? No doubt. Is it worth ditching a load of code we already have and take the time to learn how to do it well? Not necessarily. Are microservices cool? Absolutely. Should everyone use them? Definitely not.

People who see "Go is great" and immediately start down that path do not understand that context is everything.

None of us remembers particularly well. No one can run all of the code in their head. The future person who has yet to join your team doesn’t even get the chance to “remember” the reasoning for the decisions that we make today.

So, what I mean is this, we think of jQuery as the tool and the website as the product. Or Angular as the tool. Insert library.

This keeps us in a hamster wheel of learning to use tools to build products, rather than building products to solve problems.

The software is not the goal. The solution is the goal.

I see this as a human issue in lots of fields. Carpenters love to debate dewalt vs makita vs milwaukee, but it's the thing built with the tool that matters, not the tool.

Imagine carpenters striving to learn how to use different brands of circular saw. We debate angular vs react vs jquery. Why do we care about that?

Because that is about us rather than the product. I know jQuery. I know angular. Angular is better than react, therefore I am better than you.

That is the opposite of humility. That is arrogance. We are stuck in a loop of solving the problem of solving problems. We need to get to the next level.

I see it now with Canvas vs DOM.

I think that a lot of the stuff people take for granted in modern programming languages would've been considered clever tricks or just complex and alien mechanisms by the average programmer around when I started 25 years ago (remember serious business that ran on basic?).

The way mainstream code looks today has changed a lot compared to then, and I predict it will still change a lot.

Hubris and flying too close to the sun is what has always pushed tech forward and turned average software developers into legendary ones, both for their success and for their failures.

Transcript : https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...

Dijkstra wrote a lot of "deep but not really" quotes that makes perfect headlines and generates clicks and traffic for your blog. Doesn't make them good advice. His full articles are better but people just use the short quotes and writes blogs based on those.

The "business value" of software optimization is not well known.

People like humble people, but don't think they are as good as people who act confident or even arrogant.

For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce.

Not so humble.

[1] http://threevirtues.com/

So is humility underconfidence ?

Is their a word for the right amount of confidence ? Maybe confidence ?

No, it's just that non-trivial efforts tend to be heuristic in nature.

The issue mostly arises because Thinkers are prone to expressing confidence while accepting of criticism. But more people (feelers) are humble yet violently opposed to criticism.

But yeah, it’s good to not unnecessarily crush incompetent egos when it can be avoided... unfortunately some people are just too sensitive and even not encouraging them is seen as an attack on them.

By the way, I was agreeing with you.