Hacker News new | ask | show | jobs
by coldtea 4031 days ago
My problem with most languages is not that they are not perfect. Not perfect I can understand and work around.

The problem is that they go out of their way to add some batshit crazy stuff like this, or cripple themselves without a reason, when they could be so much better with small and simple additions.

Would it be so difficult for Javascript to not ever have those crazy silent coercion rules and have lexical scoping by default? It would have been a trivial compiler change back in 199x when JS was designed.

Would it be so difficult for Golang to have a proper generics system from the start and be done with it?

Would it be so difficult for Java to add closures 10 or so years ago?

etc...

2 comments

There is a difference between "not having features" (even not having features by design) and going out of your way to design an absolutely terrible solution to a problem that is, AFAIK, not used in any other language out there.
Yeah, this Nim thing is on the top of the crazy list...
Why is it crazy? I've wanted this feature recently in other languages. Just because someone else wrote FunctionName doesn't mean that I want to write it that way.

Case insenstive search solves the matching problem adequately. You could also do underscore-insensitive searching.

Why is it a problem, or crazy? It's a natural extension of being insensitive to whitespace and formatting. If you like your code to look_like_this, fine. Someone else PrefersThis. It can all interoperate. I think that's great. Leave style to each person's preference.

>Just because someone else wrote FunctionName doesn't mean that I want to write it that way.

If it's different codebases, you can do that in almost any language. Have some comebases write fooBar and others write foo_bar or whatever, whatever each one prefers. It's not very good even in that case, because you'll often have to read somebody else's codebase (which is why people praise go fmt and organizations have coding guidelines), but at least there it's OK.

But if you're talking about FunctionName and functionName and function_name in the SAME codebase (and obviously you do, since for the previous case you don't need Nim at all as I said) then that's were madness lies -- willingly impairing yourself to identify optically a symbol to be the same as another or not, because it can have 20 variations...

I've never found this "flexibility" and bike-shedding that ensues useful in any language. I'd even prefer a fixed brace style, even it's not the one "I like". It takes a few weeks of familiarity to learn to perfectly see a different formatting style and even "like it".

If we were following this idea, then I think source would be displayed according to your preference whenever you looked at it. You'd never need to deal with multiple symbol variations. The goal would not be to use multiple styles in on code add so much as make style entirely personal.
> Leave style to each person's preference.

That's fine for hobby projects. That's pretty much the last thing you want for a codebase of a significant size. I don't like C#'s style conventions, for instance, but I'd rather work with a language that has uniform style conventions I dislike than in the free-for-all you get with Nim.

Python's "There should be one-- and preferably only one --obvious way to do it." applies to style as well.

Some more examples:

C to have been designed with a proper string type...

Size of array not part of its type for Pascal?

Fucking named constants in CSS?