Hi, thanks for your feedback on your own issue.
> Correct, I'm lazy and I wanted to know if someone had this idea before me.
Laziness is not a good starting point for something like this you know,
because it mostly means you're asking people to do things you could very
well do yourself for yourself. There is a fine line between asking for
help because it is the most effective way forward, and asking for help
because you can't be bothered to help yourself....
> :)
I'm basically insulting you and you're smiling in response? :P haha.
> Yes, I thought to "mainstream" programming languages.
Right.
> In fact I thought to code reduction.
> For example, to highlight all the identifiers we have to handle the
> identifiers. Refactorings like inlining or extracting require handling the
> identifiers too, and so on.
Okay I don't know exactly what you mean, maybe something like what
Facebook does to its Javascript code? They replace all occurrences of all
identifiers with the smallest possible replacements that are possible as a
matter of short strings being used. So if you examine their code, you will
not find anything other than "a" or "vx" variables and function names. You
can bet that's not how they wrote it, but they minimize the data
transmission in terms of JS code and CSS descriptors, all the while using
such elaborate automation schemes that the code that is left is still huge
beyond comparison. So all of their visible code is generated and packed
and extremely hard to debug by a user. You can't really see what it's
doing so you either have to use some real good debugging tools, or just
watch the network connections (GET queries) it tries to make as a result
of that code execution, if you want to analyse the page.
> To have one mapping, one definition of refactorings, etc.
> For example, all the OOP refactorings work in OOP languages, why shall we
> reimplement them in each PL?
> My goal is to reduce the learning time, for example, if I learn a new OOP
> PL, I don't want to learn new bindings, I just want to learn how to code
> with it and I know that OOP Principles don't change.
You are talking about VIM bindings for the plugins you use, right? So this
is only a personal goal right? So you are intending to spend an awful lot
of time developing a framework for yourself so that you can save time on
learning some new editor bindings every time you learn a new OOP
language?.....
How often exactly do you intend to do that? I know I'm being inquisitive,
but I just want to help you become clear on what it is you want to do, and
not end up asking other people for help on something that would only be
valuable to you if someone else took the pain of actually doing it for
you..........
I mean it is perfectly fine to ask for help, but not on something that you
just want to be done FOR you so you can be a lazy ass mofo ;-).
And I'm being this inquisitive because if someone else goes and helps you
while not understanding what you exactly want to do, it will not end
up helping you anyway.
So get a grip on yourself! People don't learn a new programming language
every few weeks. /Not even you/ :D. The number of mainstream languages is
extremely limited and the number of native OOP languages even more so.
Like, there is OOP in PHP but it's not exactly the mother of OOP
languages. What I've seen of Python thus far doesn't seem like hugely OOP
either. Then there's Ruby, which is also an interpreted scripting language
as far as I know. Then you have the nearly deceased Java and what is left
is C++/C#/Objective C and all that stuff.
OOP in PHP is particularly strange. PHP has these weird concepts of error
handling that I fail to grasp in their essence. I'm only familiar with
Wordpress but it serves a case. Most if not the vast majority of exposed
functions in Wordpress (all of it is exposed if it's not in an object) are
just plain functions that are suitably named to avoid namespace
collisions. All the error handling that exists seeems to be catered
towards debugging your code instead of handling proper fail protection.
Then they provide a OO layer if you want it, in case you want your code to
be really user friendly and reusable. Part of that extention is the thing
called "exceptions" which is neat and all but no native code uses it so
you can only use it as a wrapper around the core functions or (likely)
your own low level functions. So what it comes down to is that you end up
manually checking NULL conditions all over the place, which is tiring,
more so when a function can return both "NULL" and something else that
evaluates to false. And you *can* provide a seemingly-neat OO wrapper that
does graceful error handling (try, catch). But you will have to define
every single Exception class that you need if you require any
differentiation.
Then there is Python. Excellence par excellence in terms of graceful error
handling. I've never used it, yet, but that code is NEAT. I guess it is
very much OOP, don't know the scope of that yet. But very very different
from something like Java or C#.
So all in all I really honestly believe that the goal of wanting to have
one-size-fits-all refactoring application or whatever is just an idle
fancy that you should let go off, and instead try to figure out what the
real thing is you want to achieve, which will be much easier to
accomplish, I am sure.
It is a common experience of many tech helpers that people come to them
and ask about specific solutions that are vague and elaborate, when after
a while it turns out that the problem giver has skipped a few steps and
settled on a supposed "wanted" solution when it's not what he/she really
wanted after all. Meaning, perhaps you are being too specific in what you
want and you should backtrack and explain more of your feelings.
Anyway, good luck.
Xen.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment