Hacker News Reader

Comment by gwbas1c | Hacker News Reader

I can just imagine the learning curve when encountering legacy code in a language that's only used for the project, product, or company. I can't begin to explain how many times I have just Googled a question in a particular programming language and very quickly found an answer. When I work in new or unpopular languages, I often can't find an easy answer.

The difference in time is staggering. The learning curve for a popular language means that learning something new takes me 5 minutes, but in an unknown language learning something you could take me all day if there are not a lot of things like stack Overflow posts.

If a project specific custom language deviates too far from the norms, then it means that incoming programmers will have a harder time maintaining it.

View on HN

Having seen all kinds of abuse of C macros or python metaprogramming I can't even imagine the mess this could create. Some people just seem to love the idea of creating a undebuggable Frankenstein macro system just so they can save 3 characters of code when writing foo.bar instead of foo["bar"]. Python libraries depending on @ annotations everywhere is another favourite. You save 1 measly line of code by not having to call or register the function somewhere but you loose so much more as you can't control initialization order and your program usually is forced to store it's data as global state.

I do see the powers and benefits this can give but with great power comes great responsibility. It must be truly isolated to places where you absolutely need it instead of just for fun.

Oh my god - this. I have recently started writing my own library that required to register functions for the task runner. At first I’ve tried to copy the @ approach, but then realised what an unmaintanable mess that becomes.

> I can just imagine the learning curve when encountering legacy code in a language that's only used for the project, product, or company.

I've seen some pretty extensive class libraries that required a lot of study to understand, so I'm not sure a DSL makes a difference.

One aspect of a DSL is its relation to the way business folks talk about their jobs and the jargon they use. A DSL can get you pretty close to matching how a process is described by the business in business terms. I am reminded of an old Dr. Dobbs Journal article[1] about Botanical Latin. It seems like from an understanding and conversation view a DSL has a pretty good fit at a lot of businesses.

At the end of the day, a lot of programmers are trying to implement business solutions and not trying to create new web products.

1) http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Web...

There is a third circle of hell: kdb. Unpopular and what is there is unsearchable as the syntax consists of items like ,:/.

I like kdb and the docs are okay, but my word...

Not easy to get into indeed but I find it a pleasure with some experience. Personally I find k/q nicer to work with than say Ruby as used in Rails.

Reply on news.ycombinator.com