Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

One of the languages I have to use at work is a very small, niche language called psl. One of the largest complaints I have about it as a language is that the libraries are very limited.

While that's understandable for a small language developed by a couple of guys, it does cause me some dilemmas. Specifically, I find myself "rewriting" functions that are standard in other languages because they don't exist here.

This is especially problematic when I'm attempting to write a function to solve a problem, and management doesn't want to spend the time to do so. They want me to use hard coded magic numbers instead, which I know will need to change multiple times over the life of the code.

This doesn't quite fit the antipattern reinventing the wheel because it didn't exist here in the first place. What kind of anti pattern would this fit?

share|improve this question
2  
Is it possible to link to compiled libraries written in other languages? That might help mitigate the problem to some degree... maybe? –  FrustratedWithFormsDesigner Sep 12 '11 at 15:01
17  
Stupid managment antipattern –  Tom Squires Sep 12 '11 at 15:02
11  
Looks like psl is guilty of the "obnoxious music on their homepage" antipattern to me. –  Brook Sep 12 '11 at 15:06
1  
Reminds me of the time, in 2005, when I found myself writing resizing scroll bars using graphics primitives, for similar reasons. Call it the "our new language is awesome, who needs libraries!?" anti-pattern. –  Steven Burnap Aug 28 '13 at 1:17
add comment

3 Answers 3

up vote 17 down vote accepted

Writing functionality that doesn't exist in standard libraries or as usable COTS or OSS solutions isn't an anti-pattern. It's a necessity driven by the technology stack that was chosen. If an inappropriate technology stack was chosen for the project simply because it was used successfully before, that's an example of the Silver Bullet anti-pattern.

Using magic numbers in your code, instead of isolating them into configuration settings or as constants is an example of the Magic Numbers anti-pattern. As FrustratedWithFormsDesigner mentioned in the comments, management dictating design details is also a sign of micromanagement.

The project might be experiencing the Vendor Lock-In anti-pattern, if technology was chosen and software designed in such a way that it is difficult or impossible within a reasonable amount of effort to change the libraries and tools used.

share|improve this answer
3  
Yeah writing these functions isn't the anti-pattern, it's management insisting on magic numbers that's the anti-pattern. –  jhocking Sep 12 '11 at 15:11
    
Hmmm, that's probably why it feels odd. Multiple anti patterns at the same time. –  Spencer Rathbun Sep 12 '11 at 15:37
4  
@jhocking: Actually, that sounds like a Micro-management anti-pattern... Why does Management get this much say in how the OP writes their code? –  FrustratedWithFormsDesigner Sep 12 '11 at 15:47
    
Those things aren't really anti-patterns they're just bad. –  Daniel Little Aug 28 '13 at 1:22
add comment

I see this forking in one of two different roads. My first inclination is that of code smell, an indicator of a deeper problem. Why do you need to use a custom niche language?

A. Because your company has found it worth the time and effort to do so.

Then, you are not "reinventing the wheel". The language is new and offers enough added-value to merit the time investment for new functionality.

OR...

B. Because you are being elitist and/or otherwise made a bad decision.

You started reinventing the wheel the moment you decided to invent your own language to solve problems that can already be effectively solved with other, more mature languages.

share|improve this answer
    
The company I work for picked the language, not me. –  Spencer Rathbun Sep 12 '11 at 15:40
1  
@Spencer Rathbun - It's irrelavent who made the original decision. As a developer maintaining this product, you are responsible for other people's past decisions, good and bad. –  P.Brian.Mackey Sep 12 '11 at 19:47
add comment

Not sure about going back and changing code, but it will definitely lead to breaking the DRY Principle.

Taken from the link above:

The DRY (Don't Repeat Yourself) Principle states:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.