Hacker News Reader

True, however some languages have much less 'sick part' than others. It is just unfortunate that we humans tend to pick up the worse of everything. There is some hope though. In recent years there are many projects trying to provide a better programming experience and safer, faster results. Rust, ReasonML for example.

I have yet to find a better programming experience than Ruby myself, but Rust looks fine for systems programming, etc. I don't understand however why people invest so much effort in Javascript. The amount of tooling around it just baffles me, but again, to each his own.

Ha, I can understand how you're baffled. As a primarily-front-end dev working with JS most of the time, I'd say the reason why it's worth it is that there's currently just no other language that runs in the front-end, or that is as ubiquitous a scripting language.

Much as my dislike of JS grows as I venture further into other programming ecosystems, I still love the ability to muck about with any web page I come across. I love being able to use the Chrome/Firefox devtools for debugging, and haven't found anything quite as nice outside of the browser. I love being able to package a bunch of js and a minimal html file, and just dump it anywhere that provides basic hosting.

It only barely offsets the many problems I have with JS, but because my day-job is mostly front-end, I need to deal with these problems anyways.

But man I'm looking forward to a situation where I could use <preferred language> as a drop-in replacement for javascript.

I really like Javascript, I just don't like it when you use it in React applications and the like. It feels a lot like overengineering.

Want to muck around with websites with JS: https://bookmarkify.it/ (Disclaimer: shameless self-promotion on my part)

Seems kind of silly to compare client-side Javascript to languages that have no client-side solution.

That might be more of a chicken-egg situation. One might argue that you could take even a hundredth of the effort that has been put into Javascript and put it towards an alternative and you'd come a long way.

Also, I am not against Javascript at all. I just don't understand the role it has been given on the back-end. There are better languages and on the other hand I don't agree with the amount of engineering that goes into front-end applications that are built in things like React. It seems silly to me to rebuild standard functionality of your browser in a framework in order to gain some interactivity that was already there to begin with through plain-old-javascript. Rather than invest all that time and effort into React, Redux, Redux-sagas, Ember, Vue, etc, etc, etc (there are a whole bunch of etc) people would have spent their time a lot more productively if they'd help out with making web components happen properly.

Yes! this so much. I remember a coworker who had to do an Interface or Abstract class for everything in Typescript. Only because typescript provides those features doesn't mean they should be used everywhere.

saying that all languages have issues is definitely painting things with a broad brush. Why would I want to use an unmantanable slow language when I can use a fast maintainable language.

I find Ruby to be a very maintainable language. I use Ruby with Ruby on Rails which is a great framework to create web applications and the like. I would not use Ruby if I were in the system programming space as it is too slow and not strict enough. Every purpose can have a different language that is great for it, but don't forget that every programmer also has a language that is good for him. I, for example, will never work with PHP again because I find it ugly and I don't get happy working with it. Rust looks great though, when I find a purpose for it I might give it a go.

Ruby's slowness is often mentioned, but Ruby is quick enough for many situations. I am very productive in Ruby and servers are cheaper than developers so for many purposes it works out just fine. I have tried Phoenix (Elixir) and I found it too verbose and complex to work with. I am sure though that others love it, so to each his own.

If you haven't discovered issues with your language of choice then you haven't used it enough

Saying that all languages have some sort of idiomatic issues therefore there's no point complaining about language X is a fallacy that attempts to completely sidestep the issue at hand. You have to admit that although they may be Turing complete, all such languages are not pragmatically equivalent and some have significant pain points, possibly more impactful than others, otherwise we'd all code in INTERCAL and be all the merrier

I once wrote (by hand, over 3 or 4 pages) a program to add (I think, been >20 years) two integers using a Turing machine. I can definitely attest that not all languages are equivalent.

This statement is a platitude. A: "Kim Jong-un is bad". B: "If you haven't discovered issues with your government then you haven't lived there long enough".

So, why would one want to use the negatives from language X, when one could be using the positives from language Y!

> so many programmers breaking up everything in useless classes and methods/functions/whatever just because someone wrote a blog post about doing so. This just makes complicated code look simple at a glance

Thank you

I've seen people create classes containing only a string or a list/array of other (existing) objects, it's not even funny anymore.

> I've seen people create classes containing only a string

That can be a good way to improve type-checking in code that would otherwise pass around bare strings. It reduces the chances that e.g. a plain text string is confused with an HTML string.

If your language supports it, an opaque type alias would be more explicit:

https://flow.org/en/docs/types/opaque-types/

Yes, if the auxiliary class either checks or transforms the string in some way I agree

But that's in specific cases, not all cases

This is one of the biggest reasons for code becoming unmaintainable. Many people got mad at DHH for speaking ill of TDD, but he is not alone in pointing fingers at blindly restructuring code for the sake of (unit) testing as mentioned in the article.

I get why people would like to pretend that everything is made up of beautiful uncomplicated small pieces, but that is not how life works. At some point you have to understand your tax returns, mortgage contracts and communications with incoherent external APIs. Making me jump to section 4.1.2 and from there to section 7.2 in order to understand the parties mentioned under 1.1a are subject to the rules set out in Appendix A section 42.1 does not make the contract easier to understand. So why would code that feels like a legal document be easier to understand?

That's a really good example of the problems of indirection. I'll use it in future if that's ok. The thing that drives me mad about the promoters of decoupling is that they rarely talk about the downsides. The truth is that every time you decouple something there is a cost in complexity. One individual step to decouple something may seem small but the cumulative effect of many indirections in code can make it extremely difficult to navigate and understand. So when people decouple something they should understand this and make sure that the benefit outweighs the cost (which of course it does in some cases). The benefit of being able to test your code at a micro level rarely outweighs the cost.

Thank you, yes please do. You nicely explained what I feel about this 'advice' when it is formulated compulsively like in the article. You made me think 'yes, exactly that' with regards to some people who seem to ignore the downsides of decoupling. Thank you for that, I'll refer to your comment in the future. Nice to come together like that.

> I don't really see how this would be much more different from language to language. The being 'sick of' part, not so much the specific irritations. Every languages has its issues and from all the languages I have tried I have found Ruby to be the most pleasant to work with, but I am sure this is different from person to person.

And yet I never see people getting sick of functional programming after a few years. People either try it and dislike it immediately, or they switch and don't go back.

There really are better and worse languages, better and worse ways to write software.