What is this page about?
After reading this page, you will understand why Pineapple is born, and what kind of problems it aims to tackle.
According to the author of Clean Code, Uncle Bob, the main reason that causes software maintenance to be expensive is due to poorly written code.5
Although the main culprit of dirty codes are programmers, I believe that the other reason might be due to the programming language itself.
Hard to write clean code.
To write clean code in those languages, oftentimes you need to adhere to some military discipline or zen philosophy, or else you might shoot yourself in the foot.
So, this is why Pineapple is created, it is here to solve the difficulties in writing clean code.
In other words, Pineapple is here to reduce the WTFs from developers.
Factors that promoted dirty code¶
In summary, the primary factors that promoted dirty code are:
Hard to create understandable functions
Too many ways to create functions
Hard to extend existing classes
Hard to create understandable functions¶
The main reason that prevented programmers to create understandble functions easily is that most programming languages still bares similarity with Assembly Code.
1 2 3 4 5
# Assembly MOV A, B # Python send(a, b)
From the code above, we can see that both Assembly and Python does not differ much. They both have the following characteristics:
function name comes before arguments (a.k.a. prefix-oriented)
arguments position are ambiguous
to understand what the function means, one usually have to lookup for its definition
In short, it is unnatural. Because we don't speak in such manner.
In general, all our instructive sentences have the following structure:
<subject> | <verb> | <object> | <preposition> | <object>
<subject> | <verb> | <object> | <preposition> | <object> John, | bring | the apple | to | kitchen.
There are several ways to emulate the sentence above in programming languages, but none of them are as clear and concise as the English sentence.
1 2 3 4 5 6 7 8
# procedural bring(john, apple, kitchen) # object-oriented john.bring(apple, kitchen) # name parameters bring(person=john, food=apple, destination=kitchen)
That's why sometimes, no matter how much you cook your brain juice, you just can't figure out a name that is good enough for your function.
The solution to this problem is mixfix function. Mixfix means that the name of the function can be separated into many parts.
// Pineapple john.bring(apple to kitchen)
In this case, the names of the function is
Some programming languages like Smalltalk and Agda actually had this feature.
Too many ways to create functions¶
Most programming languages offers the flexibility to create functions using different construct such as :
static class method
1 2 3 4 5 6 7 8
// To convert Integer to String (123).toString() // To conver String to Integer? "123".toInteger() // <- Oops, this is wrong // The correct way is: parseInt("123") // <- WTF?!
Such inconsistencies can increase the learning curve, moreover when we decides to create a new function, we might hesitate, because we are not sure which construct to use.
Furthermore, this causes weird looking code:
1 2 3 4 5 6 7 8
# decoding a JSON data result = json.dumps(data.encode()) # is json an object or namespace? # it could be better if it looks like this result = data.encode().toJson() # OR result = toJson(encode(data))
Due to the consequences of having too many ways to create functions, Pineapple only provide one way to create functions, which is using free functions.
Due to the reasons above, I decided to create a new language called Pineapple to resolve those issues.
Glass, R.L., 2001. Frequently forgotten fundamental facts about software engineering. IEEE software, 18(3), pp.112-111. ↩
Lientz, B.P., Swanson, E.B. and Tompkins, G.E., 1978. Characteristics of application software maintenance. Communications of the ACM, 21(6), pp.466-471. ↩
Pearse, T., and Oman, P., 1995, October. Maintainability measurements on industrial source code maintenance activities. In Software Maintenance, 1995. Proceedings., International Conference on (pp. 295-303). IEEE. ↩
Galorath. 2017. Accurately Estimate Your Software Maintenance Costs ↩
Martin, R. C., 2009. Clean code: A handbook of agile software craftsmanship. Upper Saddle River, NJ: Prentice-Hall. ↩
Shneiderman, B., 2010. Designing the user interface: strategies for effective human-computer interaction. Pearson Education India. ↩