free roaming design patterns

I'm a self-taught programmer. I did not learn programming for the
purpose of making money, but for the joy of writing code, solving
problems and automating tasks. Thus, I belong in an entirely different
set of programmers, the lone wolves, those who never participated in a
project.

Differences go on: I wasn't involved with teaching institutions and
had adopted no teaching system. I studied only what made sense to me
at the time, programming languages, algorithms and data
structures, in a chaotic manner. The way I understand programming is
that I have a problem, and I need to find ways to automate it, or get
from point A to point B; how I'll do it is something that I figure out
naturally - I put no "meta" thought to it, as if it's obvious. As you
may have figured already, my coding style is chaotic as well; there's
little consistency to it, which is a kind thing to say, as others
would call it cryptic the least. In other words, my code is completely
personalized.

I never felt the need to study what is known as 'design pattern'. I
intrinsically know every design pattern there is on wikipedia (I was
curious enough to check). In fact, I may even not know it, but I will
certainly come up with it when the requirements are such.

Am I being elitist about it? Certainly. That's why the only programming
board I frequent is /prog/.

kill yourself faggot

In business, people need structure to control how the employees do their work. Such structure assists in things such as consistancy and expectations. People also need names for these ideas. 'Design patterns' is the name for the idea that patterns can be found in the implementation/design of one or more software and that these patterns can be made generic to be reused in other software solutions.

>>3
Code reuse was a marketing gimmick from the late 90's

>>3
It is the name for the idea that people who are in charge of programming force their programmers to use languages that are not suited to solving the problems at hand, requiring the substitution of convention for core forms.

Fuckin'litists

I expect that 9 out of 10 programmers learned programming primarily for "the joy of writing code."  So, the only thing that distinguishes >>1 from the average programmer is that he has less training and less experience and isn't aware of design patterns.

>>7
BS. What do you mean by training? As for experience, not having participated in a project doesn't mean you're inexperienced.

>>8
It means your inexperienced at particpating in projects

>>1
So what you're saying is that you're like every other programmer but without any ability to communicate.

Being smug about your own ignorance isn't the same thing as being elitist.

ITT angry java programmers

>>11
more like being a hipster, ^amirite?

>>11
Or isn't it?

in my opinion design patterns as a phrase is overrated and overused and as a concept is worthless.  the majority of what are called "design patterns" are obvious to any excellent programmer who sees the same problem more than once.

strict adherence to following existing patterns stifles innovation as programmers become afraid to innovate.  it enables less competent programmers to hide behind convention as they celebrate the simplest of concepts - like "object oriented"¹ programming - as revolutionary, amazing ideas that deserve to be celebrated and revered for eternity and need to be incorporated into every project.

-- university educated ENTERPRISE programmer


_____________________
_{¹i'm talking about object oriented programming as implemented by today's most popular "OO" languages}

>>15
Design patterns are worthless as a concept, what does that mean?
Patterns appear in code, that is unavoidable. I'm wondering, perhaps
you mean that giving a name to each of these patterns and describing
them in layman terms is what's of no value. What worries me more is
your notion of excellent programmer; the fact that he'd stumble in a
problem he'd never seen before, or the fact that there's a minority of
design patterns not obvious to an excellent programmer, which is more
bothersome?

(plus, OO isn't simple)

Sure is /g/ in here

>>15
The idea is about identifying common patterns in the design then making that pattern generic in order to make it reusable in other designs. As a result of being generic, it will only solve generic problems and so, it is up to the developer to decide whether it is feasible to modify the pattern to fit the problem (thus making it non-generic).

>>15
Fuck off, George.

Are we still having the design pattern argument? Design patterns exist to bridge short-comings in the programming languages they're used in. Better programming languages make them superfluous. That's it.
Jesus Christ.

>>20
Hey now, let the idiots have their fun

>>20
Haha, oh wow!

>>20
That's right. Most of what is known as ``design patterns'' (as coined by the Gang of Four and used in SEPPLES, Java and other popular single inheritance ``OOP'' languages) are mostly workarounds of shortcomings or lack of features ot better express certain abstractions. If you want to see how most of those design patterns disappear in better languages take a look at: http://norvig.com/design-patterns/ most of them become just natural expression of the language without the need of complexity that appears in their original descriptions, others are just language features or can be easily expressed using current language features.

Of course, the term design pattern can be used to talk about certain kinds of abstractions without needing all the baggage the examples in the GoF book, but few people use that meaning when speaking of design patterns.

Oh and I forgot to say one more thing:

>>1 you need to read SICP. Learning to build better abstractions and how to organize your code is how "code reuse" actually works.

I find myself reusing generalized libraries I wrote myself or other people wrote all the time. When you're solving a specific problem, the solution may be specific, but various things can be generalized and abstracted away into libraries which may be of use to you later, especially if the kind of problem you're trying to solve is similar to another one you already did. Of course, if what you're doing is completly novel, you're going to write a lot of new code.

>>24
I've read some bits of SICP. I've quit mainly because of a loss of interest.
>>24
I've read some bits of SICP. I've quit because of a sudden loss of
interest. I'm quite familiar with abstractions and code
organization. It's just that everything in my code is personalized, ie
I can make sense of it while you probably need a lot of time and some
thought to it.

I don't do the 'code reuse' thing most of the times. I remember back
in 06 when I used to code in C I had implemented a <llist.c, llist.h>
that I'd use whenever I needed - I rarely do that anymore since the
languages I use are either terse or full of standard features (and
sometimes, in case of CL/Qi, both).

Do I write over and over again the same code that I've written so many
times before? I suppose that happens, unavoidably; I've solved many
problems and I've wrote much code over the years, enough to classify
as "experienced programmer without any experience".

I don't care for a v2; I don't want patches; I write my code in such
mindstate that dictates me to bulletproof everything, compute whatever
is to be computed and be done with it. If there might be a need for
features in the future, I'll implement a module system or script
language of the sort, but maintenance? Who cares!?! Plus, that's true
only for half the code I write; the other half is code I write to
research problems, code that is going to be used only by me and
whoever else finds the same problems interesting on the internet;
Yeah, I have the priviledge to be chaotic there.

>>25
In the case of CL, it's somewhat true, I rarely use any standard OO "code patterns", as I can express them more nicely using language features(macros, passing functional values/closures, lambda lists(keyargs/restargs/optargs), CLOS/MOP, etc), however I also make use of libraries other people wrote or my own, examples would be things like:
- system definition facilities (like ASDF)
- compressor/decompressors
- common format serialization/persistence
- regular expressions
- disassemblers/assemblers/emulators
- utility libraries
- collection/graph libraries
- http/irc/smtp/pop3/imap/etc client/server(s)
- compilable binary format description language(s)
- FFI/interfacing with external systems
and so on. A lot of these libraries are perfectly reusable, and when they don't fit exactly, they can be extensible, and re-inventing themselves is usually a major waste of time, especially since what is currently available is already good enough most of the time. Of course, when you're just experimenting with general problems which have not yet been solved, or whose solution does not please you, you might not need to use anything except the base language (especially in fairly feature complete languages like CL), which can be enough.

Okay, motherfucker. Don't line-wrap your shit when my browser does it for me. It's a waste of space and pretty fucking jarring.

>>27
You just don't understand his genius, man.

30 Name: Anonymous 2011-02-04 18:40

---

Don't change these.

Name:		Email:
Entire Thread Thread List