Oasist Blog

Deliver posts regarding linguistics, engineering and life at my will.

Pros and Cons of Script Languages

f:id:oasist:20201106131903p:plain
Script Languages

Contents

1. Introduction

To excuse myself first, what I will write from now on is just my personal opinion and I do not intend to insist on that is correct at all.
Rather, I long for comments from readers.
So I would be happy if I could share what I think are pros and cons of script languages here to logically put into words, not emotionally.

I used to work as a system engineer of a system engineering service firm.
I cut my teeth on Ruby on Rails when I changed jobs for the first time, which triggered my Ruby learning.
Since I majored in it when I was a university student, Linguistics has been interesting to me and I came to bagin to learn Natural Language Processing.
That is why I have mastered Python.
It was by chance to learn Ruby and Rails, both of which are script languages.
I have never any compile language although I learned Java when I was in the first career.

Experience provides something sweet and bitter, and we can find such blogs that shares them.
So you might think the contents of this article are what you have already seen.
Thank you for your generasity in advance.

2. Pros

2-1. Easy for "Beginners of Programming" to Write and Run

I feel as if I work on a composition and can run it particularly when I write codes in Ruby.

This sense is a huge merit for me because I knew nothing of programming until a couple years ago.
I am good at writing and reading, so this skill makes for smooth Implementation and productivity.
Also, something is absolutely wrong if I feel weird to the codes in terms of module coupling, naming and business logics, so the skill is also useful in debugging and refactoring.

However, some afept programmer of C lang do not believe Ruby or Python is comfortable to write.
For example, assignment of a negative value to index of an array causes crash, but Ruby and Python do not.
That is why I laid stress on "Beginners of Programming".

2-2. A Lot of Communities and Workshops

As of the release date of this article, I have never joined any Python community or workshop yet, but I can say at least Ruby has them.

Programming might be seen as self-study subject.
Is is surely true and we cannot acquire any skills without it.

But, it is also quite important to discover new knowledge and broaden our perspectives by get acquainted with the third patry.
It will prevent our selfish coding.

Still, we will get a relief if we know someone who has in common both sweet and bitter experiences.
This mental influence is more influencial than we expect.

2-3. Organised Official Documents and Tutorials

It is very painstaking to find knowledge in web browsing where we face countless fake information.
Trustworthy official documents make huge differece in this sense.
We can prove to not only others but ourlselves why we implement it in this or that way based on convincing reasons.

3. Cons

3-1. No Absolute Correct Answer for Implementation

Ruby on Rails has a principle of CoC(Convention over Configuration) and it keep the framework flexible. There is an official coding convention, but the consent varies from community to community.
So the more "correct answers", the more organization.

If it works wrong, those spagetti codes show up which somehow behave correctly although they are too messy to read.
In other words, readability depends on the implementor.

Easiness of writing provides the surprising initial speed under a circumstance where people, stuff and money are not affluent and time is limited.
But things are different in the long run in terms of meintenance which is vulnerable to close module coupling and devastating class designs.

3-2. Maintenance Dependence on Human Resources

THe cons are outstanding especially in such a framework as Ruby on Rails.

Java raises errors in compiling codes, so behaviours are guaranteed by the configuration. On the other hand, we do know know if there is an error until we run codes in Ruby and Python.

As I mentioned before, so-called spagetti codes somehow behave correctly.
So wrting test codes is important to explain why they behave right.
We can enjoy a lot of meris by it, and the most important is we pay attention to requirements tracing back to test codes. TDD(Test Driven Development) is not always applicable(is is needed to fix all requirements are fixed then), but we at least come to be conscious of what behaviours are required and what test codes are needed to prove them, so it enables us to write clear codes.

However, only Implementation with test codes are warrented, so the coverage varies from case to case.
This fact leads to maintenance dependence on coders.

Spagetti codes without test codes are qualified enough to be called industrial wastes because they causes astronomical costs in updating the language and libraries.

It should be believed we must at least write unittests for what we implement.

3-3. Used by the Framework > Use the Framework

Recently, I have come to think I am happy with Ruby but not with Ruby on Rails.

Pure script Implementation in Ruby and Python kicks my ass to delibarate optimal logics and test codes, which seems make me happy.
Yet, I scarcely feel so in the Rails Way codeing based on the convention.
This is brought by the optimisation thanks to the hardworking committers and it is definitely great outcome that security level is highly guaranteed without much coding.

As paradoxical as it may seem, it seems to make me feel like I am rather used by the framework than using it.

4. Conclusion

I like both Ruby and Python because they enable me to vividly visualise algorithms, but I am not happy in team development.
I am yearning for such Go lang and Java as time goes by nowadays.

It may be high time to learn compile language although I return to script languages saying "I have come to prefer them again!!"