Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term.
I am doing a startup!
Cross-browser testing from your browser!
I have written my fourth book!
Be faster than Larry Wall in the shell!
You're viewing a comment by Brett and its responses.
Have you heard of "not invented here" syndrome? This article is practically preaching that anti-pattern.
Frameworks are about code reusability and not reinventing the wheel. Are you saying that you roll your own logging solution for every project? Refuse to use ORMs and prefer to write every SQL statement by hand when performance is not yet an issue (premature optimization being another anti-pattern).
I'm not sure what frameworks you've had experience with, but this sounds like a problem with the frameworks themselves or their usage.
Learning curves might be a downside, but the upside is that if a new employee already knows the framework, your project has -less- of a learning curve. As they don't have to learn your custom in house crap that does the same thing.
Could not agree more!
ORMs are just making things more complicated. It's not a big deal to write SQL statements. Also logging is not a big thing, maybe you could save typing some code, but that would take only an hour or so.
Hmm David, I would like to test your apps againt SQL injection. Would be intresting. ORMs are great when it comes to the point of code reading or efficiency. When you avoid ORM you just making your life harder.
You don't need an ORM to avoid SQL injections. All you need is to encode the query params. And then? That's it.
The advantage of an ORM is *just* to make it look like a bad OOP language. Everybody should know that SQL != OOP. Each technology needs to be used appropriately.
ORM and efficiency should never be used in the same sentence.
Obviously you never came across the concept of being platform independant..
Can you please elaborate, like, how is SQL platform dependent and ORM is not. I don't understand where you are pointing with your sentence.
I was using an ORM and I learnt SQL just yesterday and now I don't know what all the fuss is about. To defend against SQL injection you only need to call a function. So you have more lines of code, but that's it.
So basically you copy&paste that line all over your code?
Copy&Paste programming is bad, okay?
You are sure to mess up sooner or later, and if not you, then the maintenance programmer who has to keep your stuff running after you left the company (or the project or whatever).
Boilerplate code is bad, too, okay?
Ideally, each line of your code does something important, and functions and objects abstract away any details below the detail level of your code at that point. That (and a number of other things) makes code readable and maintainable.
At best your extra lines take up monitor space needlessly. At worst they distract from or even drown out what your program really is supposed to do. (IDE code generators are quite like snorting acids up your nostrils to deaden your sense of smell against the stink of boilerplate code.)
Finally, the *correct* way to handle SQL injection is always using place holders in your query (and binding any variable data to them).
Not only is that pattern distinct (and more noticeable when not used), it also allows the DB to compile, cache and optimize the query. That comes handy when you handle larger amounts of queries and data --- i.e. when bad database performance is most noticeable.
So the only defensible answer would be: "I use a single function/method/routine/... that handles all SQL queries and their input data and there all the data is escaped before it enters the query."
Wow, you heard of SQL injections. Here is a star, bro. Now, can we continue with productive arguments, please? SQL injection is not a problem inherent to use of SQL as such. It is partially relevant when user is able to compose their own SQL queries, for malicious or other use. Talking in favor of ORM because it eliminates the threat of SQL injection makes you sound like a cool weekend hacker on a weekend hacker conference. All the other hackers will clap and tap you on the shoulder because you namedrop all the cool buzzwords, but a computer scientist will just recall why he went to college instead, where he learned what potential advantages and disadvantages of ORM and SQL are.
"When you avoid ORM you just making your life harder." -- I think what you wanted to say was "When _I_ avoid ORM, I just making my life harder." Don't impose your limitations on others.
Also, read up on ORM mapping problems. I am sure you don't have them, probably because you don't take your underlying data model into account, but some of us do care.
Dave, in all honesty, I think you should accept Catmans proposition -- free test for SQL injections, man, that stuff don't arrive in the offer box every day.
Sorry but this is a very stupid statement. Then why use a high level programming language at all? C is not that difficult.
Abstraction is important.
C is certainly not difficult, if you're careful enough. You don't need to learn a lot of concepts to understand it. You just need good coding skills to use it.
Use a high level language if you want more productivity. It's the same with ORMs: you can get more productivity, but then your software won't be so elaborated. It may be fine for some people. I would say that the difference is that there are more drawbacks of using ORMs than a high level language.
You seem to be conflating libraries with frameworks.
I'm completely lost on the "use an ORM instead of SQL" to avoid premature optimization." What? SQL is an optimization now?
One could argue that an ORM is an anti-pattern.
ORMs are not a framework, they are a library which the author doesn't have a problem with. Frameworks are overarching where an ORM is usually just back end.
First of all, there is a wide area in between rolling your own and using a framework. Libraries comes to mind. Second, ORM has not solved the mapping problem in a definite manner, there are still some open questions left, being tackled differently and with different degree of success by different ORM frameworks and libraries. There is nothing wrong with SQL, it has been around long enough and is considered to have met its design goal of facilitating data queries. Using SQL instead of ORM is arguably not premature optimization, but a system design decision. Third, I hear too many times people rebutting framework criticism with "I dunno, you must be using some weird frameworks". In my educated opinion, frameworks have you trade in development freedom in return for providing efficiency, but the problems this entails, as listed in the article, are *inherent* in the concept of frameworks, and to a much lesser degree in which particular framework it is. I.e., all frameworks suffer from the points the article outlines, but indeed the better ones are attempting to address them at least. Still, the median value makes the points valid, in my opinion again. Fourth, employees can and should be expected to know certain fundamental things as well, such as abstract data types and perhaps application of different programming paradigms and best practices, even controversial ones. The fact that they know React or Angular or some other framework is secondary to these other things, and if they know these things, your argument that knowing a framework is somehow beneficial is a matter of managements preference. If it's a shop that needs to save money and thus floats on frameworks all day, that's fine. But don't shoot the author down with a comparison to "in-house" crap -- like I said, there is plenty of things to choose from between in-house crap and a framework (which may be somebody elses in-house crap turned into export product).
Frameworks are the opposite of code reusability. Where can you reuse unless it's another project w the same framework?
Lol don't be too hard on them, thinking for yourself is hard these days.
(why do I need your e-mail?)
It would be nice if you left your e-mail address. Sometimes I want to send a private message, or just thank for the great comment. Having your e-mail really helps.
I will never ever spam you.
(Your twitter handle, if you have one.)
* use <pre>...</pre> to insert a plain code snippet.
* use <pre lang="lang">...</pre> to insert a syntax highlighted code snippet.
For example, <pre lang="python">...</pre> will insert Python highlighted code.
* use <code>...</code> to highlight a variable or a single shell command.
* use <a href="url" nospam>title</a> to insert links.
<a href="url" nospam>title</a>
* use other HTML tags, such as, <b>, <i>, <blockquote>, <sup>, <sub> for text formatting.
Type the word "unix_508": (just to make sure you're a human)
Please preview the comment before submitting to make sure it's OK.
Peter Krumins' blog about programming, hacking, software reuse, software ideas, computer security, browserling, google and technology.
Reach me at:
Or meet me on:
Subscribe through an RSS feed:
Subscribe through email:
Enter your email address:
Delivered by FeedBurner
See all top articles
See all downloads
See more detailed list of recent articles
See more detailed category information
See more detailed list of all articles