Reinventing the wheel

[QUOTE=itmitică;5103858]It’s just… ironic. She’s worried about performance, she’s telling me this

yet she “proudly” uses Wordpress.

<hr>

She may be not talking absolutisms, but she’s childish in her approach.

[/QUOTE]

As far as I know, she’s a front-ender, not a programmer, so I don’t see how that comparison holds up…

Well, if that, a big disclaimer is what’s missing from her article.

Like this one, from comments:

Gaëtan Voyer-Perrault

As much as you are defending “wheel re-invention”, you did not re-invent the wheel at all. You simply duct-taped a one-off solution to a very specific problem.

[QUOTE=itmitică;5103871]Well, if that, a big disclaimer is what’s missing from her article.

Like this one, from comments:

Gaëtan Voyer-Perrault[/QUOTE]

That may be true, but in my opinion it does not invalidate the general thesis.

Which is…?

If the answers are these:

[…]reinventing the wheel can’t be bad when your new wheel improves existing wheel designs, right? Well, not if the software is open source[…]

Then

You hardly ever need 100% of a project. Given enough time to study its inner workings, you could always delete quite a large chunk of it and it would still fit your needs perfectly. However, the effort needed to do that or to rewrite the percentage you actually need is big enough that you are willing to add redundant code to your codebase.

she

A big one is maintainability. This code won’t only need to be parsed by the machine, it will also be parsed by humans, that don’t know what’s actually needed and what isn’t until they understand what every part does. Therefore, even the simplest of changes become hard.

needs

I didn’t want the phrases to include HTML, since I didn’t want to have to escape certain symbols.

a better

I’m the only person writing these phrases. Even if more people write translations in the future, they will still go through me.

understanding on how things really work in a proper programming environment. So many bad choices, so many wrong assumptions.

<hr>

If anything, I’d consider her “thesis” an argument for not wanting to team up with her on any project. If she wanted to come across as a viable back-ender she only managed to unimpress me by presenting her findings of regex as a turning corner in development.

I’m doing i18n my self and I can honestly say she’s going the wrong way with it. Once you face a developing challenge you better solve it in a reusable way. Looking for fast unique patches means more work in times when you probably will not have the luxury to redo that in a proper way. Hence, a next patch, and then another one, and your fast coding quickly turns into heavy stones drowning you.

[QUOTE=itmitică;5103907]Which is…?
[/QUOTE]

Which is what this thread is about and what stomme poes has formulated very accurately in her original post.

From a high level, I agree with the overall premise of the article - if you would only be using a miniscule fraction of the framework, then don’t use it if you can get the same performance with a smaller footprint. It’s better for your customer and better for their clients with better performance.

The problem with catch-all frameworks is their complexity, and often people can’t find all the pieces without a ton of digging, which means they end up looking elsewhere and using ANOTHER framework (say jQuery + mooTools + the flavor of the month), or a plugin which has actually been replaced in the baseline code, but the documentation doesn’t lend itself to knowing it’s been replaced.

The other problem is layering - people put code on top of code on top of other code instead of refactoring constantly like they should always be doing. So you end up with 10 different ways to reach the same solution, then people add onto those 10 different ways, which adds a magnification problem on top of a simple solution…

I still have my old college professors mentality - keep it light and tight - when I approach ANY technology problem. The fewer layers I have to deal with, the easier it is to fix a problem when I go back to deal with it later. I’ve got a problem right now which is a pain in the maximus simply because there are too many files (at least 10) required to accomplish the same goal, and one of the biggest hurdles is the framework that was chosen wasn’t flexible enough to handle anything other than straight table/database interaction.

Frameworks are great for what they’re intended for, but they shouldn’t be the be all and end all. They are tools to help you do the best job possible with the least amount of effort. HOWEVER - if you become solely dependent on them and can’t do the simplest tasks without using them, then YOU’RE not a developer.

I guess I belong in the other end mentality. Whenever there is new project, I ALWAYS search for new weapons to play with (doesn’t mean I pick a new one for every project). There are few rules on which I choose… for example, I never use anything less than 2.0 versions. Also, there are successful be all and end all frameworks. You can google “Spring Framework”. This framework is so big and covers so much area that you can literally create any type of projects. In fact, this framework was sold to VMWare for cool half billion dollars! It is still free to use but they rake in the cash for training courses. It is no surprise that this framework is the #1 used Java frameworks.

With that said, I don’t agree with “Keep it light and tight”. I go with “Keep it smart by doing less”. At the same time, it is foolish to pick a weapon you don’t know how to use… YOU CAN CUT YOURSELF! It’s like nunchuck used by bruce lee and myself…there is a vast difference how it’s being used.

I guess I just don’t have that “oooh shiny” attitude. I decide what I want the website to do, then I figure out how to do it. It’s very rare that I’ll come across a new toy and then decide to add it to a site. It’s a case of doing what I need/want to do, rather than showing off what I can do (or rather, what someone else can do).

I don’t have “oooh shiny” attitude. Instead, I have “How can I make it better and faster for next project?” attitude :wink:

There are two sides of the coin.

<hr>

N00bs would work and reinvent the wheel, it’s just that they don’t know how, so they turn to libraries instead

That’s assuming libraries are targeted to n00bs, since they can’t actually learn the language. Which is pretty much not true. If a library makes it easy for n00bs, it doesn’t mean the library is for n00bs and n00bs only. Or that any n00b could easily pick the library up and hit the ground running.

The truth is that libraries are for reusable code, for DRY code. And, most importantly, for productivity. Those that worked on projects beyond a certain level will probably understand that better. Using libraries and then finding spots where they don’t fit, or where a couple of lines of “vanilla” code are more suitable, really shows a flaw in the app design, which it’s certainly not an occasion for a developer to gloat, duct-tapping the holes.

<hr>

Seasoned developers dismiss libraries and would work on how to reinvent the wheel because they know how to

That’s assuming seasoned developers actually find it easier to learn how to use a library. Which is pretty much not true. A developer may find a particular library involves concepts it’s not qualified for, so it does things the way it knows instead. It “reinvents the wheel” thus admitting its knowledge and skills have limits too.

The truth is that it should learn, it should fill in the gaps in its knowledge and then it should move forward, like the rest. Or it should provide a better alternative. Or, if none of the above, it should understand it doesn’t really understand the topic.

I have my own perspective on this. We don’t know everything and we certainly can’t know everything, but apart from that something happens to make the world go round, and that something is money.

People won’t pay for custom work like they used to. I find myself using libraries in order to reduce the price on things to accommodate what people can afford. For me the two most important aspects of a website are security and support, in my humble opinion.

I’ve now found myself reducing the price with ready-made templates and budget logo’s. Even thought I can’t produce an awesome logo, I’d like to think I can produce a pretty neat website. Having said this people won’t pay for a tailor made website. They all want to reduce the price, and when I give them a second option of templates and ready-made library and plug-ins, they always choose the cheapest option. Do you see how it works?

How much would you need to make your own CMS? Even so, how good would you have to be in order to compare to some of the open source platforms out there.

I do use Theme Forrest and there are exceptions when the stuff from there is pretty amazing. I don’t feel ready made jQuery is bad. I’ve seen some examples which are pretty shocking and unusable in most cases, however, jQuery is not bad, and considering we have to learn jQuery I would hate to imagine what learning javaScript would be like.

We should learn and evolve what we learn, so maybe I should learn javaScript.

… and that right there says EVERYTHING that’s wrong with the majority of people who use jQuery…

I do have to commend you for rightly criticizing the person who shows inexperience, rather than the library.

@Sega My apologies that you had to be singled out. Deathshadow and I are more generally talking about people who are still learning JavaScript. Nothing personal against you.

Those are very valid points.

What I don’t understand is why you generally oppose to the idea of reinventing, or to put it differently, reformulating something when the scenario permits it or when you feel that the solutions which exist don’t fill the bill or could exist in a trimmed-down, more apt version for a given task.

I understand that you find the example in the article above problematic. That’s fair enough.

But ignoring the Markdown example, what I don’t quite understand is why you would generally negate the idea of the article, the underlying, broader thesis behind it; that a work by someone can and should be taken apart, reformulated, or approached with a completely new methodology when you, as a developer, and with the tools (your skills) think you could come up with a better solution for a task without compromising reusability or efficiency.

I’m not in any way implying that existing applications are bad, nor am I against jQuery and the like, but I don’t see how there can’t be room or valid scenarios for using alternative concepts.

I’d have thought that the general philosophy behind this approach would be right down your alley, Mitica.

[QUOTE=itmitică;5104491]There are two sides of the coin.

<hr>

N00bs would work and reinvent the wheel, it’s just that they don’t know how, so they turn to libraries instead

That’s assuming libraries are targeted to n00bs, since they can’t actually learn the language. Which is pretty much not true. If a library makes it easy for n00bs, it doesn’t mean the library is for n00bs and n00bs only. Or that any n00b could easily pick the library up and hit the ground running.

The truth is that libraries are for reusable code, for DRY code. And, most importantly, for productivity. Those that worked on projects beyond a certain level will probably understand that better. Using libraries and then finding spots where they don’t fit, or where a couple of lines of “vanilla” code are more suitable, really shows a flaw in the app design, which it’s certainly not an occasion for a developer to gloat, duct-tapping the holes.

<hr>

Seasoned developers dismiss libraries and would work on how to reinvent the wheel because they know how to

That’s assuming seasoned developers actually find it easier to learn how to use a library. Which is pretty much not true. A developer may find a particular library involves concepts it’s not qualified for, so it does things the way it knows instead. It “reinvents the wheel” thus admitting its knowledge and skills have limits too.

The truth is that it should learn, it should fill in the gaps in its knowledge and then it should move forward, like the rest. Or it should provide a better alternative. Or, if none of the above, it should understand it doesn’t really understand the topic.[/QUOTE]

Seasoned developers dismiss libraries and would work on how to reinvent the wheel because they know how to

Am the only one who felt awe struck when I read this statement… I can’t be the only one…

@Jeff_Mott;
I will get learning jQuery, but I don’t see a point learning JavaScript. We did it at university, but that was a long time ago when things were all pop-up and equations. We learned nothing we could use in actual practice, so I left it out in practice and no employer demanded it of requested further training. Nowadays people use jQuery and MooTools rather than writing javascript from scratch, which works for most.

Yep, you’re right.

People seam to be doing without learning JavaScript, maybe we should open a thread which highlights the benefits of using JavaScript as oppose to libraries (excluding the learning is fun part). Once people see the benefit they are missing out on they would naturally attempt to learn something.

That should be an extremely rigid scenario for one to do that. It’s like saying “For this particular project I’ll never ever use arrays. I want a PHP version without arrays.” That’s Epiphany talking for you. You’ll later pay heavily to the mother of all, Experience, to counsel you to never ever waste your time again and fall for that.

Me standing behind jQuery is me appreciating “someone can and should be taken apart, reformulated, or approached with a completely new methodology when you, as a developer, and with the tools (your skills) think you could come up with a better solution for a task without compromising reusability or efficiency”, don’t you think? :wink:

I like alternative concepts. I like jQuery over vanilla JavaScript, aren’t I?

<hr>

The gist of it is that I stand behind one learning programming concepts and finding smart ways of making use of them rather than feeling accomplished by burring its nose down to the level that it won’t see the forest because it’s looking to closely at the trees. Reinventing the wheel to me is to forget about priding in overcoming petty problems for a certain implementation of a certain language but always look at the big picture of abstract, universally valid programming concepts.

For clarity. What I mean is that there are developers well versed in a language. Yet they may find a library way of working to be something so radically different that they just throw in the towel. Or maybe they just lack the knowledge it takes to get it. The fact is that they find it easy to just stick with what they already know and they try to reinvent the wheel. Meaning that they can’t adapt to new concepts, they can only work and understand their own personal way. Usually, it ends up costing them.

Gotcha. I completely agree. Many talented programmer easily dismiss a open source framework because they don’t understand. Most are too proud to admit that they don’t understand… so they come to “This framework sucks” and try to sucker you into agreeing to use old / custom codes.

[QUOTE=itmitică;5104608]That should be an extremely rigid scenario for one to do that. It’s like saying “For this particular project I’ll never ever use arrays. I want a PHP version without arrays.” That’s Epiphany talking for you. You’ll later pay heavily to the mother of all, Experience, to counsel you to never ever waste your time again and fall for that.
[/QUOTE]

That doesn’t quite address anything I’ve said. Fact is, jQuery wouldn’t have come to life if someone didn’t reinvent the wheel and just used the Javascript frameworks that already existed, so we have to thank the developers of jQuery for not having followed your principles.

Same goes for PHP and other languages. They could have used what existed then, but they didn’t extend it but instead created something new. Someone somewhere felt that new situations required new ways of thinking.

But I’m leaving this discussion alone now as I’m going in circles and simply differ in opinion. :slight_smile: