Post #182,134
11/1/04 11:35:59 PM
|
Time for good anti-OO battle to take minds off of election
> I wish to expand my horizons. But also when I've developed analysis tools
> with graphical interfaces in Igor Pro, I really started to wish that Igor
> supported some OOP concepts. I found myself writing a lot of related
> functions that worked on a common set of data, for instance, and I wished
> I could create classes to keep them all in.
Grouping is more complicated than OO material often makes it sound.
There are usually multiple candidate factors which a given
unit of code can be grouped around. However, with text program
code you are generally forced to choose one primary grouping,
making compromises in the process.
Further, what data structure something uses in many cases
should be considered an implementation detail to be hidden
away from interfaces. OO teaches implementation hiding, yet
*violates* this very concept by encouraging one to design
interfaces around and group code around nouns or data sets.
I have yet to hear a good justification for this from
OO'ers.
But back to the multi-factor grouping issue, there is
No One Right Grouping. Any grouping you choose is a
compromise.
However, I tend to minimize this issue by moving as
much into a database as practically possible. The
database becomes the "noun model", not OO classes.
(It takes some practice to "attribute-tize" things
one is often used to being in behavioralistic code.)
Then, when it is in the database, I can search, sort,
filter, and group the information almost any damned way I
please. How I see it is controlled by me and me
alone! Databases have made me a selfish bastard,
and have spoiled me. But not to fear because anybody
else can also see the very same information how they
themselves want it, not dictated by somebody's goofy
doctrines or mantra. Thus, I don't have to force my
info views (such as grouping) on them. You can have your
cake and eat it too!
It is based on a fundimental computer-science
principle:
Separate Meaning from Format
Code-centric approaches generally violate this, but
OO'ers don't seem to care.
Even Microsoft is moving in this direction with their
Common Language Runtime system, which makes programming
language choice less relavant. (However, it is not
currently based on relational principles, but I think
in the long run that will change. Relational is superior
to the "navigational" data system they currently use.
It will just take a few decades for the machine-power
to catch up. Higher abstractions generally require
more horse-power.)
The general principle is that there are more "maths"
for data-centric views than for behavior-centric
views. Thus, the more that is converted into data,
the more "maths" we can apply to it. Maybe someday
there will be a "Dr. Codd of behavior", but until that
happens, data-centric is where the power of
abstraction and the power of machine-guided virtual
transformation currently resides. (Dr. Codd is the
originator of relational theory.)
Thus, let's take advantage of it.
________________
oop.ismad.com
|
Post #182,141
11/1/04 11:48:17 PM
|
Sorry cant go there
I need an language that is table/OS independent that both tables and operating systems code to meet pre-developed definitions rather than code to specific tables/OS. Write once run anywhere can only be acheived by a
get object.desc and if you want to meet the reqs, your table will understand what I want and give it to me.
regards,
daemon
that way too many Iraqis conceived of free society as little more than a mosh pit with grenades. ANDISHEH NOURAEE
|
Post #182,149
11/2/04 12:29:33 AM
11/2/04 12:39:02 AM
|
How is being locked to a DB more evil than being locked to
a specific language?
If you don't want to be locked to a vendor and want to see the DB code, then go with an open-source DB. If you don't use a DB, then you often end up reinventing what database already do:
# Persistence
# Query languages or query ability
# metadata repository
# State management
# Multi-user contention management and concurrency (locks, transactions, rollbacks, etc.)
# Backup and replication of data
# Access security
# Data computation/processing (such as aggregation and cross-referencing)
# Data rule enforcement or validation
# Data export and import utilities
# Multi-language and multi-application data sharing
If you reinvent all these from scratch, then how is that being less "locked in" than an open-source DB? You are simply locked into your own code instead of somebody else's. Over the long-term you probably move on and the next person who comes along has to deal with and learn your non-standard database or its equiv. Isn't it better to get the above features from a semi-standard tool to avoid such a huge learning curve and reinvention? Remember "reuse"?
________________
oop.ismad.com
Edited by tablizer
Nov. 2, 2004, 12:39:02 AM EST
|
Post #182,159
11/2/04 2:11:14 AM
|
It's best to fit the tool to the job
Fact is, databases are so generic that they fit no problem space. Enter additional layers, specifically frameworks and ORMs, which allow the app developers to encapsulate the generic DB in a domain-specific "little language", thereby reducing complexity. When you can express the same code in fewer terms, you can express more in the same time/space/effort. When you can express the same code in terms from the vocabulary of the domain (as opposed to the vocabulary of the tool, the DB), you save a mental translation step; this reduces time-to-market, miscommunication among developers, and ultimately design and implementation errors.
This is the same reason LISP doesn't take off in popularity--it's too generic. You need a guru to write a "little language" in LISP that enables your problem space; then you can build the killer app on top of that. Visual Basic swept the small business app world because it was tailored to small business apps. This reduced choice and expressivity, but by the same token increased speed and made small business app "programmers" a commodity.
Databases simply don't provide the tools to produce such a grammar between the application domain and the database domain. And they never will; it's in their best interest *not* to, because to do so would reduce their market. A general-purpose programming language does provide such tools.
|
Post #182,192
11/2/04 9:40:01 AM
|
Thanks for that ... +5 insightful
That's the best answer I've read to that issue. It confirms my experience that whatever the problem space is, you always start by writing a "little language". Then you write your app using that. Very well put.
===
Implicitly condoning stupidity since 2001.
|
Post #182,228
11/2/04 11:07:35 AM
|
For various definitions of "start" ;)
The incremental guys would say you start both processes almost simultaneously. I tend to 1) model on paper, 2) write a prototype, 3) rewrite the prototype a couple times, incorporating the "big lessons" I learned along the way about the domain, 4) deliver the final. Now if I were to write essentially the same app again, I'd skip step 2 and most of 3, but who wants to write the same apps over and over? ;)
|
Post #183,101
11/5/04 2:16:06 PM
|
On writing the "little language thing ..."
I remember I once read a statement for ESR (Eric Something Raymonds)
in which he said, that he believe in the school of "make it a language" ...
by "it" I think he meant any program, I don't remember where exactly I read this statement of his, and search but failed to find the article.
But I remember vaguely that he was speaking about RMS and Emacs ...
Anyway this statement stuck in my head (even though I didn't fully grasp it, and don't up until now!)
And I always looked at emacs, as a program that was writen as a language, probably from it's first days.
The thing is, I think, many people have a different idea in their heads, when that say "language"
Elisp is a language ...
Emacs can be seen in an abstract sense as a language .... seperate from Elisp, a language that speaks, C-c C-x , and M-x append-to-buffer <RETURN>
A Class public methods is a language, the language that this class speaks
Any module that you write or language extension (actually in Tcl a library and a language extension are the same thing, also in Tcl some commands (that have a dozen sub command) will be considered as modules in other languages)
The shell command 'find' is it a command, or a module or a language!
Expect, is it a Tcl module, or a tcl command, or a tcl extension, or a language in its own
Gnome or Kde ... can't we call those a language !
Well I believe if you are talking abstractly, then yea of course, any UI or GUI is a language
Even this forum is a language
So what is a language?
If the solution is to create a language (not a program, not a module, not a command) than I need to know, what is a language, what is it composed from, when do I know I completed my language, what feature do I need filled to have a complete language.
I find this way of thinking interesting, and I would like to investigate the school of "make it a language", if it truely exist a bit more ...
Many ppl repeat those words about writing your own mini language or high level language ... so something good must be in it, specially since, that at an abstract level this thought is supported, that any program can be viewed as a language, any library, can be thought of as a language
What is missing is, how can this way of thinking, help me create a better program (language) or better module (language)
I think we can start by having a better or a more specific definition of a 'language'
Also, I want to mention, that read in a few article about Ruby, that ruby makes it very easy to write your own mini language, what a tease, as if every body is doin it, yet, when I search, I can't find any book or article who tell u how to create ur own language, the school of "make it a language", is far from ...
being an everyday thing! It's really not that popular, or elaborated upon.
|
Post #183,105
11/5/04 2:41:32 PM
|
Suggestion
Read [link|http://www.paulgraham.com/onlisp.html|OnLisp] to see "the make it a language" philosophy demonstrated very clearly.
It is not necessarily so much that you create a language from scratch (though you can), often it is that you adapt an existing language to give it the vocabulary that you need for your project.
Or as [link|http://www.pragmaticprogrammer.com/ppbook/index.html|The Pragmatic Programmer] says, you want to Program Close to the Problem Domain. Create interfaces for yourself that hide implementation details so that you can stop thinking about how stuff is implemented and start thinking about the end problems in a natural way.
Cheers,
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
|
Post #183,140
11/5/04 5:34:56 PM
|
"Little Language" definition, components
So what is a language?
If the solution is to create a language (not a program, not a module, not a command) than I need to know, what is a language, what is it composed from, when do I know I completed my language, what feature do I need filled to have a complete language.
Many ppl repeat those words about writing your own mini language or high level language ... so something good must be in it, specially since, that at an abstract level this thought is supported, that any program can be viewed as a language, any library, can be thought of as a language Correct; the difference between a "program" and a "language" is one of perspective. You write a program to walk 100m, turn right, walk 110m, turn right, walk 100m, turn right, walk 110m, and maybe turn right. You write a language to go around the block, instead. What is missing is, how can this way of thinking, help me create a better program (language) or better module (language)
I think we can start by having a better or a more specific definition of a 'language' Short answer: [link|http://en.wikipedia.org/wiki/Formal_language|read up on "formal languages"]. A little language possesses a vocabulary of functions, classes, modules, and packages which map to concepts in the problem domain. The elements of the vocabulary interact according to a formal grammar. The concepts are determined by self-declaration of human stakeholders, subject to systematic analysis and organization in order to produce a formal system. Also, I want to mention, that read in a few article about Ruby, that ruby makes it very easy to write your own mini language, what a tease, as if every body is doin it, yet, when I search, I can't find any book or article who tell u how to create ur own language, the school of "make it a language", is far from ...
being an everyday thing! It's really not that popular, or elaborated upon.
As Ben pointed out, you don't start from scratch when writing a "little language". You start with a generic language (like Ruby or Python or LISP), make up some new primitives (like go_around_the_block()), ignore any primitives which you don't need, and end up with a slang dialect which fits your problem space. It's called "little" because it's embedded within another, larger language. Ruby "makes it easy" because you can override almost any primitive (even builtin types) to create the behavior that you want. Python doesn't allow you to override builtin types; you have to subclass them. Cameron Laird [link|http://groups.google.com/groups?th=6c6790175731d644&seekm=m66s52-91c.ln1%40lairds.us#link8|made this point] nicely just this morning on c.l.p.: Next, Python thumps Java on readability and maintainability. While I don't yet know how to make an iron-clad objective case for this briefly, I'm utterly convinced that Python programs are significantly easier to read "six months later". This matters: much of teamwork is dealing with source code that one doesn't understand. Traditionalists promote Java as a statically-typed language, but this is just a distraction; Python's more graceful expressiveness leads to relatively more focus on correct algorithms and unit tests, while Java is relatively mired in syntax. Programming in Java feels too often like dealing with Java, whereas Python is a leader in letting developers think they're dealing with the application.
|
Post #183,710
11/9/04 7:34:59 AM
|
On what makes it easy to do little languages.
Double plus agreement on the "little language" explaination.
Ruby "makes it easy" because you can override almost any primitive (even builtin types) to create the behavior that you want. Python doesn't allow you to override builtin types; you have to subclass them.
I've done several "little languages" in Ruby and although the primitive thing can help, the biggest aid in doing a little language in Ruby is its ability to control the execution of a block of code. I've used Ruby to define mini-languages to (1) control build processes ([link|http://rake.rubyforge.org|http://rake.rubyforge.org]), (2) define data base schemas, (3) define FSM state transitions ([link|http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/118962|http://blade.nagaoka.../ruby-talk/118962]) and (4) build XML structures ([link|http://onestepback.org/index.cgi/Tech/Ruby/BuilderObjects.rdoc|http://onestepback.o...ilderObjects.rdoc]). In all cases it was the Ruby block that made the resulting mini-language natural and easy to use.
The builder example (#4 above) is particularly telling. The idea came from Groovy (another language that supports code block) and was insanely easy to implement in Ruby. I can imagine that doing it in Lisp would also be easy. But I've seen attempts to reproduce it in languages that don't support code blocks (e.g. Python at [link|http://users.binary.net/thehaas/cgi-haas/blosxom.cgi/comp/python/xmlbuilder.html|http://users.binary....n/xmlbuilder.html]) and the results have always been less than the original.
--
-- Jim Weirich jim@weirichhouse.org [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #183,751
11/9/04 11:01:58 AM
|
Good point.
Python comes closest to that by having first-class functions (meaning, you can pass them around as objects). But Ruby's blocks are still miles ahead. Of course, LISP macros take the cake in that department. ;) Something else I thought of in the shower: dynamic languages win in the little language department because they allow the developer to express a concept in the most appropriate syntax/semantics. For example, you're not stuck implementing go_around(person, community.get_block(13)). By dynamically adding/trapping attributes, and by overriding/subclassing builtins, you can write (Python examples):
- go_around(person, community.block[13]), or even
- go_around(person, community[13])
- person.go_around(community[13])
- blocks(13, person)
- community.blocks.13.tour(person)
- person.morning_walk += blocks[13]
...etc., any of which "does the same thing". This allows the designer to make a "little language" which is easier to use and extend. If you like TIMTOWTDI, you could implement them all simultaneously (but you probably shouldn't).
The Sig: "Despite the seemingly endless necessity for doing
so, it's actually not possible to reverse-engineer intended invariants
from staring at thousands of lines of code (not in C, and not in
Python code either)." Tim Peters on python-dev
|
Post #182,231
11/2/04 11:54:53 AM
|
Orthogonal to DB usage
I agree about the "little language". However, I have not seen OOP do that better than procedural, and second SQL is generally a pretty compact language. It is hard to beat it on code-size (even though SQL stinks in many ways). Jones' study hilighted that pretty well. Sometimes one can use a combination of SQL and "custom language" routines. Example: \n func displayEmployees(criteria) {\n sql = "SELECT * FROM emp,other_tables WHERE "\n sql .= " [join stuff] and (" . criteria . ") ORDER BY foo"\n rs = query(sql)\n while (row = getNextRow(rs)) {\n do_stuff_with_row(row)\n }\n }\nNow we can pass it a boolean criteria expression to filter our rows. It is tough to do these kinds of things with "flat" API's. Plus, one can develop and test it as SQL first, and then paste it into the routine. ________________
oop.ismad.com
|
Post #182,247
11/2/04 12:46:40 PM
|
That's actually a good idea
Then all you'd have to do is put the dynamic query building into a method of your DB object so you don't have to re-write the [join stuff] and (" . criteria . ") piece for every function. Ooh, and you could also handle escaping user-input values in one location instead of re-creating it everywhere.
Oh wait, that's what I do with my -- as I said above -- DB object. Or did you think OO proponents had never thought of dynamically building their SQL?
===
Implicitly condoning stupidity since 2001.
|
Post #182,257
11/2/04 1:24:08 PM
|
*Snork* beat me to it :)
|
Post #182,958
11/4/04 9:58:12 PM
|
Cure worse than the medicine.
Then all you'd have to do is put the dynamic query building into a method of your DB object so you don't have to re-write the [join stuff] and (" . criteria . ") piece for every function.
Don't need OOP to do that. However, putting wrappers (OO or procedural) around SQL tends to bloat up code so that you have no net savings in code size.
Or did you think OO proponents had never thought of dynamically building their SQL?
Doing and making life easier can be two very different things.
________________
oop.ismad.com
|
Post #182,967
11/4/04 11:03:11 PM
|
"tends to bloat up code"
[link|/forums/render/content/show?contentid=156638|Post #156638] I withdrawl the "bloated" claim for now. [link|/forums/render/content/show?contentid=156690|Post #156690] might be of interest to you, as well: I have no doubt that you'll sit on this for a while and then trot out, "youses never proved it wasn't bloated!" at some point in the future, so I'm calling pre-foul now so it doesn't happen. Backtracking again, Bryce...? Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #182,983
11/4/04 11:49:05 PM
|
Your "solution" to such bloat was HQL, yes or no?
________________
oop.ismad.com
|
Post #182,987
11/5/04 12:06:32 AM
|
It was a solution, yes.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #183,074
11/5/04 11:45:07 AM
|
Since you seem to be slow...
Scott's point is that you had this battle. Many times. You've lost. You've even admitted defeat.
Unless you have something truly novel to say, please save everyone time and energy by letting it drop this time.
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
|
Post #183,130
11/5/04 4:59:55 PM
11/5/04 5:00:11 PM
|
I did NOT "lose". His solution was variation on SQL
and NOT OOP
________________
oop.ismad.com
Edited by tablizer
Nov. 5, 2004, 05:00:11 PM EST
|
Post #183,133
11/5/04 5:11:07 PM
|
In your universe, perhaps
His solution was variation on SQL and NOT OOP
Let me go back to [link|http://z.iwethey.org/forums/render/content/show?contentid=156638|http://z.iwethey.org...?contentid=156638] and see.
Ah yes. Right. Scott was talking about an object-relational mapper. Which means that the overall example is going to involve a lot of OOP.
Once again you're talking out of your ass and hoping that none of us will catch where you're fudging the truth. Once again your hopes are misplaced. Please go away and try this elsewhere.
Thanks,
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
|
Post #183,136
11/5/04 5:14:31 PM
11/5/04 5:16:02 PM
|
The mapper did not reduce his code size
Ah yes. Right. Scott was talking about an object-relational mapper. Which means that the overall example is going to involve a lot of OOP.
It was not the mapper that allowed him to shorten his queries. Again, just because something exists does not necessarily mean it is better.
Plus, how come you cannot use your techniques to shorten challenge #6?
________________
oop.ismad.com
Edited by tablizer
Nov. 5, 2004, 05:16:02 PM EST
|
Post #183,137
11/5/04 5:20:03 PM
|
Bryce, you lost this one already.
I'm not going to continue this discussion. I have a job, and I have work that needs to get done. This conversation has happened before, and you've lost. Repeatedly and decisively.
If you wish to read this as, "Bryce has more free time than Ben" you'd be perfectly correct. I'll let you waste someone else's time if anyone is interested.
Regards,
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
|
Post #183,156
11/5/04 7:12:13 PM
11/5/04 7:15:01 PM
|
I did NOT fscken lose. He gave no code-size proof. Zilch.
You guys have a warped sense of evidence. Did you flunk science class?
________________
oop.ismad.com
Edited by tablizer
Nov. 5, 2004, 07:15:01 PM EST
|
Post #183,195
11/6/04 12:23:25 AM
|
Why is code size your (apparently) sole criterion?
Is it because that's the "best" metric? Please show your proof.
===
Implicitly condoning stupidity since 2001.
|
Post #183,424
11/8/04 2:43:37 AM
|
You are welcome to present ANY metric you can justify
The common common metrics that people more or less agree on are:
* Once and only once - ridding duplication
* Easier to change - change scenarios are given and the impact on code is analyzed
* Code size - less code is generally better
I am not saying these are necessarily the best or most complete, but they are the easiest to analyze and communicate about up to this point.
________________
oop.ismad.com
|
Post #183,436
11/8/04 9:05:55 AM
|
Thank you
I asked for proof of the value of your metric.
You replied that it's common and people more or less agree.
So popularity is your criterion.
OOP is popular.
Therefore, OOP is good.
Thank you for this admission of defeat.
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
|
Post #183,668
11/8/04 11:47:03 PM
|
Usually people don't question those much
If you have some better ones, then please describe them.
________________
oop.ismad.com
|
Post #183,447
11/8/04 9:25:46 AM
|
We've already been over change scenarios
Re-read the thread. You gave up on the change metric because of the branching and source code control issues.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #183,671
11/8/04 11:52:31 PM
|
re: We've already been over change scenarios
You gave up on the change metric because of the branching and source code control issues.
"Branching"? I am not sure what you are refering to. Version branching or flow logic branching?
As far as version management, the existing tools are biased toward files. I agreed to that fact. However, that is not an inborn inherent fault of tables, which was my point above.
________________
oop.ismad.com
|
Post #182,255
11/2/04 1:23:35 PM
|
"Orthogonal" in exactly the same sense as differential gears
I agree about the "little language". However, I have not seen OOP do that better than procedural... I have. When requirements change, they apply force on design asymetrically. OO allows the design to slip differentially with a minimum of effort; procedural grinds gears and breaks teeth. ...and second SQL is generally a pretty compact language. It is hard to beat it on code-size (even though SQL stinks in many ways). Jones' study hilighted [sic] that pretty well. SQL is compact because you need further code to process its results, translating those results into usable structures--this is the "do_stuff_with_row" which you conveniently left out. By mixing SQL directly into your application language (whether "procedural" style or "object-oriented"), you force the developer to manage two languages at once, manually handling the translation step between the two every time they make a choice about development. A good ORM hides that, freeing the developer to focus on the problem domain. Sometimes one can use a combination of SQL and "custom language" routines. Example:
func displayEmployees(criteria) {
sql = "SELECT * FROM emp,other_tables WHERE "
sql .= " [join stuff] and (" . criteria . ") ORDER BY foo"
rs = query(sql)
while (row = getNextRow(rs)) {
do_stuff_with_row(row)
}
}
Now we can pass it a boolean criteria expression to filter our rows. OOP: Great! You've just introduced a security hole by manually interpolating strings. TOP: Oh, but we'll never pass it unsafe criteria. OOP: And that's documented/enforced where, exactly? TOP: Fine, we'll add a comment in the procedure, documenting exactly what is considered "safe" criteria. OOP: Good. But you've got a staff of 10 developers. Who's got time to read each others' embedded comments in a library call? TOP: Fine (adding a line or two of code), we'll enforce it within the procedure. OOP: Wonderful! You missed a spot. TOP: Fine (another 10 lines of code). OOP: OK. Now do that in *every* procedure with embedded SQL. TOP: Fine, we'll abstract that into an "SQL checker" tool (adding 1000 lines of code). OOP: Nice! You've just written an SQL parser/validator. But you slowed down your DB I/O by a factor of ten (or more). TOP: Fine, we can speed that up greatly by validating each component *before* we construct the SQL string. We just need a little extra structure to say "this atom is the tablename" and "this atom is a boolean criteria string" and "this atom is the ORDER BY clause". OOP: Hmmm. It works, but you've got this huge bottleneck procedure with 38 arguments. TOP: No, I reworked it last night. Now I have 74 different procedures with slightly different argument lists for every occasion. OOP: Oog. That's really confusing. Can't we build our list of SQL atoms incrementally? Maybe there's some way to collect all those components into a single structure and then just pass that. TOP: Fine. I worked 20 hours a day for 2 weeks, but it's done: a module which builds safe SQL strings out of potentially unsafe components, and it's developer-friendly. Happy now? OOP: Congratulations. You've just written your first ORM. It is tough to do these kinds of things with "flat" API's. It's tough regardless. Why not let a team of experts do the tough parts once and let everyone benefit? Plus, one can develop and test it as SQL first, and then paste it into the routine. I'd rather have a complete test suite. Did you test the corner cases? Did you test malformed data? Did you test code coverage? Unless you've found (or written) a complete testing framework/harness within your database as well... in which case, my hat's off to you. But I haven't seen one yet. TOP may be fine for developers who have never worked on anything other than a small project, who care nothing for portability, maintainability, or software engineering (as opposed to software construction). Which is fine--lots of code is of the home construction type, where you build a small one-story edifice, live in it for life, and patch as you go. It's an asset on the books, and depreciates. Just don't expect it to give your corp a competitive advantage--that requires engineering, design, and risk management. Embedding SQL in procedural code is two-by-fours and drywall, and lots of paint. A good ORM and good OO design is pre-stressed steel, trusses, sunken piles, shear walls, and an interior designer.
The Sig: "Despite the seemingly endless necessity for doing
so, it's actually not possible to reverse-engineer intended invariants
from staring at thousands of lines of code (not in C, and not in
Python code either)." Tim Peters on python-dev
|
Post #182,261
11/2/04 2:03:26 PM
|
You just shortened this thread by 200 posts. Cut & Paste.
Congratulations! :-D We'll have to come up with another non-election related topic. Hmmm.... How about: [link|http://discuss.joelonsoftware.com/default.asp?design.4.20066.21|Is Cut and paste a Bad Design] at Joel on Software. That [Jef Raskin] is a crackpot out of touch with reality is clear from the above article where he complains that features like cut and paste don't work, are useless, and contribute to code bloat. His argument is that if you walk away from your computer for an hour after cutting, you might forget you had cut and planned to paste and your work that was cut would be lost forever. I do believe that this has happened to him frequently because he is losing his mind. Like, whatever. Cut and paste to be working for everybody else on the planet. I think it works OK and taking it out would not improve things much. Cut and paste isn't something I think about much any more. Every editor I've used has had it. Having more access to the clipboard where things are held transiently is a good idea and would solve his problem of losing track of things. [link|http://hobbes.nmsu.edu/pub/os2/util/clipbrd/mgclip02.zip|MegaClip] was such a tool on OS/2 (from the readme.txt): MegaClip is a utility to manage multiple OS/2 PM clipboards. It is inspired in part by the IBM EWS program "ManyClip", as well as by a Windows 3.1 program I used Looong ago (but have forgotten the name of now). MegaClip's key feature over ManyClip is its ability to handle bitmaps and metafiles in addition to text. Other benefits include the ability to view more than one clipboard at a time (multiple windows), to view details about the clip (date, time, size, etc), and to 'hold' one clip in the system clipboard -- even while copying other clips. Clips may be stored within the main program window or placed directly on the desktop and it is possible to turn off 'Auto-Retrieve' so that only desired clips are retained. These features are briefly explained below. I don't think Cut & Paste is the issue. You? Cheers, Scott.
|
Post #182,267
11/2/04 2:26:58 PM
|
"[Nobody] ...points out that the cut-and-paste method...
...of moving text is inherently faulty."
Nobody, that is, except Microsoft. Jef might be forgiven for only using Macs, and never experiencing Explorer's default cut-and-paste behavior, wherein, if you never paste a "cut" file, it never gets completely "cut". Or Excel, wherein, if you never paste a "cut" row, the original is never deleted.
Meh. Mr. Raskin is a smart guy, and I greatly enjoyed Humane Interface, and learned a lot. Everyone's entitled to bad ideas. "...test the spirits to see whether they are from God, because many false prophets have gone out into the world."
|
Post #182,962
11/4/04 10:44:56 PM
11/4/04 10:46:13 PM
|
No, you got me all wrong, dude
When requirements change, they apply force on design asymetrically. OO allows the design to slip differentially with a minimum of effort; procedural grinds gears and breaks teeth.I have heard this claim from many other OO proponents. I have asked for code examples, and rarely get them. The few that did produce something proved they were either using a lame language (such as C), were lame procedural programmers, and/or did not know how to use a database right. I won't take your word for it without seeing code where OO wipes procedural's ass because you may fit into one or more of those three categories (without knowing it). SQL is compact because you need further code to process its results No, I mean for what it does, it is usually compact. By mixing SQL directly into your application language (whether "procedural" style or "object-oriented"), you force the developer to manage two languages at once So far attempts to include relational algebra into a language library using imperative API's has stunk. The problem is that relational algebra is not imperative, creating a paradigm mismatch, or at least ugly bloat. Remember this joke code?: \nNORMAL\n\nprint(a + b)\n\nBLOATED\n\nam = new math.ArithmeticManager()\nopA = new math.Operand((float) a)\nopB = new math.Operand((float) b)\nam.addOperand(opA)\nam.addOperand(opB)\nam.operator = new math.operators.Addition()\nam.executeMathOperation()\nsystem.io.output.print(am.mathOperationResult())\n Scott suggested Hybernate's query language (HQL) to avoid this kind of API bloat. Hybernate is a bastardization of SQL. One problem with it is that it only works with Java. The second problem is that it is close enough to SQL that it is not worth introducing yet another standard. Rather than make SQL++, we might as well come up with a better relational language with more meta abilities and replace SQL altogether. However, if they make HQL work with any language and it is a reasonably well-supported standard, I probably would not complain much. As far as security holes, one can create procedural cleaning and/or validation functions. Example: \nsql .= "foo = 'A' and ID = " . sqlNum(myID);\n\nOr perhaps:\n\nandChar(sql, "foo", "A");\nandNum(sql, "ID", myID);\n Small and simple. (There are other variations on this theme that get fancier.)
________________
oop.ismad.com
Edited by tablizer
Nov. 4, 2004, 10:46:13 PM EST
|
Post #182,143
11/2/04 12:03:09 AM
|
Repeat after me:
There is more to OO than implementation inheritance.
There is more to OO than implementation inheritance.
There is more to OO than implementation inheritance.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #182,150
11/2/04 12:36:44 AM
|
I never said OO was JUST about inheritance.
But if you go away from inheritance, then OO is even *more* messy. Relational offers a more consistent and more viewable way to relate a bunch of information together. Objects are mostly just glorified maps (dictionary arrays) of attributes, functions, and pointers. (Robert Martin calls them "jump tables".)
Tables make better building blocks than maps of pointers for most things. Relational has better theory behind it than networks of maps. Networks of maps are shanty towns with no solid, consistent rules and a lot of work to change. There is no Dr. Codd of maps so far either. Two different people are more likely to come up with the same/similar relational shema designs than the same network of maps to do the same thing.
________________
oop.ismad.com
|
Post #182,249
11/2/04 12:52:46 PM
|
Amusing to note...
First tablizer proposes: OO teaches implementation hiding, yet
*violates* this very concept by encouraging one to design
interfaces around and group code around nouns or data sets.
Ok, got it. Designing around noun models is a bad idea.
Then ... However, I tend to minimize this issue by moving as
much into a database as practically possible. The
database becomes the "noun model", not OO classes.
Wait, designing around noun models is now good?
I'm confused[1].
--
-- Jim Weirich jim@weirichhouse.org [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
[1] Ok, I'm really not.
--
-- Jim Weirich jim@weirichhouse.org [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #182,980
11/4/04 11:36:55 PM
|
re: nouns and noun grouping
Most attributes belong to one and only one noun. However, I don't find this true with behavior. My fav pet example is "bus hits Bob". Does "hits" belong to the bus, to Bob, or both? In fact, big collisions can involve lots of nouns. In OO, one would probably make a Collision object if nouns kept getting added rather than try to associated it with one of the nouns. But I find the excercise of trying to find which noun has "responsibility" to handle collision rather arbitrary. You may have to move it from being a method of one of the nouns to being a class by itself.
As far as "grouping", things in a database can be grouped just about any way you want to see them. How they are grouped is not a design-time decision. A database is a repository of facts. How you view those facts is another matter. When you put stuff in a database you should only be concentrating on putting that fact in, not how it will be displayed. Therefore if you need a different grouping, you only change your query instead of reworking code. You can look at just the collisions that involve Bob, just those that involve the bus, all collisions that don't involve either the bus nor Bob, etc. If a relationship between one noun and another appears, you add that information, you don't move the fact being amended.
________________
oop.ismad.com
|
Post #182,986
11/5/04 12:06:15 AM
|
Bryce: control tables are bad
No, not here. Here: [link|/forums/render/content/show?contentid=157251|Post #157251]
As you have conceded in the past, TOP doesn't work for small things, doesn't work for big things, and given the discussions we've already had, you cannot or are unwilling to come up with an example where it actually does work.
I'm not willing to rehash all of this again. Did you think we had forgotten?
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #183,134
11/5/04 5:11:12 PM
|
Time will erase performance differences
Tables are not inherantly slower, but just require more powerful optimization engines to get performance. Future horsepower will catch up. Moore's Law is on my side. Higher abstractions require more horse-power. The navigational databases used by run-time engines are dinosours left over from the 60's. They only still exist because the hardware and optimization research has not caught up to fuller use of relational yet.
________________
oop.ismad.com
|
Post #183,139
11/5/04 5:24:24 PM
|
That's not the main reason why they're bad.
Recall, please, that we were talking about *maintenance* and *changepoints* and *version control*, for the most part. Please go read the discussion again in its entirety, because you've either forgotten the points, or conveniently misplaced them. That's why that whole discussion is bookmarked.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #183,157
11/5/04 7:13:32 PM
11/5/04 8:05:42 PM
|
Because VC tools are hierarchy-biased.
I agree with you that current tools are geared toward file systems and other navigational data structures. However, fundimentally, tables are a superior structure from a logical and organizational standpoint.
________________
oop.ismad.com
Edited by tablizer
Nov. 5, 2004, 08:05:42 PM EST
|
Post #183,168
11/5/04 9:19:45 PM
|
Go read the thread.
Really, Bryce, you're not fooling anyone.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #183,170
11/5/04 9:40:45 PM
|
You always talk as if I push a grand conspiracy
You seem to want to use files, grep, and XML for everything, and I want to use relational. I find relational more logical and clean than files+grep+XML. That is the bottom line. Entering info into a data table is much easier than typing the same thing into XML. For one, the columns don't line up in XML, so it is harder to see patterns. I agree that current tools and languages are better geared toward files and XML in general, but that is only a fad.
If you ignore the nuts and bolts trees of the current technology and focus on the forest, you will realize that relational is superior. One can focus on meaning instead of format.
________________
oop.ismad.com
|
Post #183,181
11/5/04 10:41:05 PM
|
Relational has its place.
You're the one lost amongst the trees.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #183,194
11/6/04 12:22:20 AM
|
Math and Boolean expressions
...don't play very well as tables, but almost everything else does. Things like run-time engines, gui structures, event-driven frameworks, etc. are becoming so complex that they would be better as relational structures instead, at least from a human interaction standpoint. Big networks of lists and maps of pointers is the GOTO of data structures. Relational offers discipline and consistency to such things in a way analogous to blocks being an improvement over GOTOs.
________________
oop.ismad.com
|
Post #183,235
11/6/04 12:07:36 PM
11/6/04 12:09:32 PM
|
Ever use Zachary?
100% control tables. Completely opaque. Great if it did exactly what you needed it to do. Impossible if it didn't. Impossible to debug when it went wrong, and horrific to maintain.
We've already been over control tables. They don't work well, and the procedural code that depends on them becomes a morass of branching (go read the thread again if you've forgotten).
Edit: I looked up Zachary. Discontinued, but you can get consultants to support it for $850 and hour. Eck.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
Edited by admin
Nov. 6, 2004, 12:09:32 PM EST
|
Post #183,423
11/8/04 2:40:25 AM
|
I will believe it only when I see it with my own eyes
We've already been over control tables. They don't work well
I do not remember any fundimental in-born flaw being given. I don't mean vendors not supporting them for version control or running too slow on Sun boxes, I mean fundimental organizational flaws to them. I have already admitted that existing tools don't play well with them sometimes, but that is because they are geared toward what I consider archaic technologies such as hierarchical file systems and file-based code. The real evil is files, not tables. QWERTY syndrome.
and the procedural code that depends on them becomes a morass of branching (go read the thread again if you've forgotten).
Please show me such code. Maybe I have an idea to fix the mess that you never thought of. I don't remember you ever showing such code. Show me an instance of control tables barfing on the rug and being fixed by objects or XML.
________________
oop.ismad.com
|
Post #183,445
11/8/04 9:23:42 AM
|
- said the blind man (ducks and runs)
--
This guy's ahead of his time! He's using quantum programming methods: in universes where invalid data is passed to this function, it does not return. Thus you are ensured that you will only have valid data after calling it. Optimally you'd destroy the universe on failure, but computers haven't quite advanced to that level yet.
-- [link|http://thedailywtf.com/archive/2004/10/26/2920.aspx|The] Daily WTF
|
Post #183,448
11/8/04 9:26:39 AM
|
NO.
I am NOT going over this again. Go re-read the threads. We've been over this before.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #183,672
11/8/04 11:55:08 PM
|
You never identified an in-born fault of tables.
________________
oop.ismad.com
|
Post #183,682
11/9/04 12:16:12 AM
|
Tables don't make good chairs.
;-j
Your zealous advocacy of tables makes me think that you don't see the value of using the right tool for the job.
The folks around here are pretty pragmatic. If you show them code that illustrates the value of your approach, and show them that your code is efficient in terms of cost of implementation, ease of modification in a team environment, and similar metrics, then you'll convince them. Until you do that, it's just handwaving. For example, Ben is a perl guru but enjoys [link|http://z.iwethey.org/forums/render/content/show?contentid=178359|Ruby]. Evidence of superiority will get you converts. Lack of evidence won't.
My $0.02. Carry on.
Cheers,
Scott.
|
Post #184,630
11/20/04 9:01:02 PM
|
Vacuum Tubes
Evidence of superiority will get you converts. Lack of evidence won't.
Well, they are at least equal. The only clear faults you have shown are due QWERTY-syndrome: interfacing to a world geared toward outmoded ideas, such as hierarchical files. A lot of companies used to resist transistors because they had tons of tools for and investments in vacuum tubes.
ease of modification in a team environment, and similar metrics
Metrics? Did you actually count stuff, or use "it just feeeeels good to me".
Your zealous advocacy of tables
How is that worse than zealous advocacy of OOP or of Lisp ess-expressions? Plus, nobody can agree on when to use what.
________________
oop.ismad.com
|
Post #184,667
11/21/04 1:28:02 AM
|
You can pry my tube guitar amp outta my cold, dead fingers.
I'll never use a transistor amp or digitally modelled piece of crap...because it just doesn't sound and react the same.
--
Steve
|
Post #184,840
11/22/04 9:04:08 PM
11/22/04 9:06:27 PM
|
Digital precision can be boring
That is because it has proven difficult to digitally model all the noise, distortion, vibrations, sub-vibribrations, and random chaos of old analog technology.
I heard a story of one guy in the late 50's who kept trying to get a certain rougher sound from his guitar. Once while in a new studio he stopped the recording session, grabbed a pen, walked over to the speakers and gouged them several times with the pen. Then he walked back to his guitar and plucked it to test the sound. He said, "Ah, now that's more like it."
________________
oop.ismad.com
Edited by tablizer
Nov. 22, 2004, 09:06:27 PM EST
|
Post #184,855
11/23/04 2:08:56 AM
8/21/07 5:54:19 AM
|
Yes - tubes are IT man
I have two copies of This Magic Moment by the Drifters. I have it on CD and can play it on modern stereo in all its digital perfection. It sounds kind of thin and inconsequential.
I also have a [link|http://www.pinballrebel.com/archive/wurlitzer/w1015/w1015.htm|1946 Wurlitzer 1015 jukebox] with some lovely 6L6 tubes and a single 15 inch speaker to play my 76 rpm version of the song. That one sends chills up my spine when I hear it.
"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." --Albert Einstein
"This is still a dangerous world. It's a world of madmen and uncertainty and potential mental losses." --George W. Bush
|
Post #184,907
11/23/04 7:04:01 PM
|
Heh! That was my first bass amp!
My old man canibalized that very same amplifier, and the speaker that came with it, and built my first bass amp with it. Note that the speaker does not have a magnet; the amp powers an electromagnet built onto the speaker (which is why the amp must be mated with that speaker). Actually sounded good, but that being the late 60's, where volume was king (Like, when wasn't it in rock'n'roll land?), I could never get enough oomph out of it. (Even overdrove the front end with a pre-amp, which didn't actually help much...)
jb4
shrub\ufffdbish (Am., from shrub + rubbish, after the derisive name for America's 43 president; 2003) n. 1. a form of nonsensical political doubletalk wherein the speaker attempts to defend the indefensible by lying, obfuscation, or otherwise misstating the facts; GIBBERISH. 2. any of a collection of utterances from America's putative 43rd president. cf. BULLSHIT
|
Post #184,956
11/24/04 2:50:23 PM
8/21/07 5:56:00 AM
|
I don't know whether to be amused or appalled
at the canibalization of such a fine device.
My lone concession to modernity is addition of improved pre-amp that allows use of magnetic cartridge/needle combo. This lets the tone-arm track at about 3 grams rather than the original 22g!
Saves on record wear. This is a biggie as jukebox records are made of tougher stuff than consumer records were. They used much more recycled material (called "flash" - the excess stuff that gets trimmed from around the disk after it comes out of the mold). The high flash content makes them more brittle and also more wear resistant (good in a jukebox record).
Of course, much of my material is either consumer records bought at junk shops/antique store or re-issued vinyl (thank you Rhino records!) which is not nearly as tough as the old juke records.
"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." --Albert Einstein
"This is still a dangerous world. It's a world of madmen and uncertainty and potential mental losses." --George W. Bush
|
Post #185,630
11/30/04 5:54:59 PM
|
Both actually
The device had already been "componentized" by the time he got it -- he just got the amp and speakers before the Original Disassembler got to throwing it out.
Although the price was right (and the 6L6GCs made a nice marshmallow roaster), It wasn't no [link|http://www.hendrixguitars.com/Images/Am022.jpg|Fender Bassman] (which is what I eventually replaced it with...).
jb4
shrub\ufffdbish (Am., from shrub + rubbish, after the derisive name for America's 43 president; 2003) n. 1. a form of nonsensical political doubletalk wherein the speaker attempts to defend the indefensible by lying, obfuscation, or otherwise misstating the facts; GIBBERISH. 2. any of a collection of utterances from America's putative 43rd president. cf. BULLSHIT
|
Post #185,674
12/1/04 12:17:12 AM
|
In negotiations
I've got a ~'70 Fender Super Reverb and an '86 Marshall JCM 800 (both amps 50W). I'm trying to trade them in on an old '65 Twin Reverb. It'll need some work, but not more than about a hundred to a hundred and fifty bucks to get it right up to snuff.
I've got my fingers crossed; the person who own it is a crotchety ol' bastard AFAICT, judging by the reaction of the store guy (owner, and I've known him for a few years now) when he was discussing my offer with him.
I'm hoping I can land it.
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
|
Post #185,676
12/1/04 12:26:42 AM
|
Drooooooooool
good luck!
--
Steve
|
Post #185,946
12/3/04 2:12:12 PM
|
Didn't get it
the guy decided when I made my offer that he suddenly wanted another three hundred bucks for it.... so fuck him.
The owner of the store pretty much said the same thing to him. He told me that I'd made the first serious offer in six months, that I was within 50 bucks of his stated price, and then suddenly the guy wanted 1750 instead of 1450. In short, he wanted the store owner's comission as well as more money from me. Apparently this is not the first time something like this has happened... so when the guy threatened to take his stuff to Toronto to sell it, the owner told him that maybe that'd be a better idea, and could he pick up his stuff on Friday?
Still sucks though; I was really looking forward to that amp.
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
|
Post #185,971
12/3/04 6:24:37 PM
|
Bum R!
jb4
shrub\ufffdbish (Am., from shrub + rubbish, after the derisive name for America's 43 president; 2003) n. 1. a form of nonsensical political doubletalk wherein the speaker attempts to defend the indefensible by lying, obfuscation, or otherwise misstating the facts; GIBBERISH. 2. any of a collection of utterances from America's putative 43rd president. cf. BULLSHIT
|
Post #185,978
12/3/04 7:29:55 PM
|
Oh well.
I traded my 70 Super for a ~mid-70s Twin instead. That means I get to keep the Marshall. I'm going to get the local Tube Genius (his name's Clint) to do some reconditioning on it.
It's got a weird feature where you can pull the Master Volume and it'll boost the gain. Sounds really crappy actually. Since this one's a 100W Amp, I'm wondering if it might not be possible to use it to switch between using only two and four of the power tubes, so I could switch it between 50 and 100 watts depending on the size of the room. Only problem I can see is that the mod might be really expensive to realise.
One Of These Days I'm gonna have to learn how to read a circuit schematic.
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
|
Post #185,998
12/4/04 1:48:50 AM
|
Talk to your amp tech
Depending how your amp's wired, you can safely remove a pair to cut the power in half without any mods. No idea if that's possible on the twin, and if it is, which two would constitute a pair. Given the lethal voltages involved, i'd definitely consult an expert.
--
Steve
|
Post #186,026
12/4/04 8:29:05 PM
|
Oh yeah
I know myself well enough to know that that's an area I DON'T want to go messing in.
That's all going to have to wait till after the holiday bills, though. What I'm kind of hoping to have happen is have a way that the master vol pull switch can be used to bring a pair of tubes online or offline. This way, the amp can be both a 50W and a 100W amp.
I really should learn how to read those diagrams... I could see how one could make money doing hand made custom built amps for the well heeled. I was talking to the local amp guy, and he said he could see doing one on commission, but that it would require some 2500 to 3000 bucks before he'd be interested.
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
|
Post #186,049
12/5/04 11:22:11 AM
|
Had a teacher who did that
Not custom amps, custom speakers for high-end stereos. His were the first I saw for home use that had the subwoofer separate from the mid/high speakers. The sub was a 2-foot cube that looked like an end table. The mid/highs were about 18 inches square and three inches deep and hung on the wall. They were as large as they were because they were packed with custom-built active crossovers, tuned to the room they were in. This was all before you could buy a tunable crossover.
For a system that you almost couldn't see the speakers unless you knew what you were looking for, it was amazing. Crystal clear even from next-door. And yes, he tested them that way.
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
|
Post #186,115
12/6/04 12:09:58 AM
|
Re: Talk to your amp tech
Heh, just passing through and see 'Vacuum Tubes' in a digitalist thread; suddenly it's 1960 again :-0
Well... you're talking about -literally- a 3 dB change in available average power ratio, especially at low frequencies [where most energy in the spectrum lies] depending on storage caps and PS 'stiffness', etc. - maybe a tad more than 3 dB difference for peaks.
You'd need the filaments on all the while, on the 'extra' output pair. But since the DC bias current through the output transformer windings affects its dynamic characteristics (ie B/H curve saturation) when it is "transforming", the power supply would have to regulate at both current levels too -- and, there's more.
ie, I think you're pining for a quite non-simple contrivance. Not clear what you think you're gaining - saving a pair of tubes? At the least, some load resistors at HV might have to be relay-switched, as would the plate leads for the spare-pair need to be opened/closed = sometimes under load* and without creating noise transients. Then there's the feedback loop, which must have correct values at both levels.
* which demands 'robust' relay contacts, which can suppress an arc.. and maybe some noise as they operate. the more I think of the consequences + how a tube amp operates:
I'd want $3K to make such a thing ~bulletproof, too - cheaper for a home-brew test box. Cheaper yet: leave them all on, all the time - and buy some spare output tubes for the next 100 years, for a lot less $. Your simple 'gain switch' could merely attenuate the input, at preamp/voltage level - no problem to contrive such a 'convenience switch', if you can find a push-pull pot/switch combo in today's Collector World [?] Prolly some of my Tek scope buddies could check their junk boxes.
(Also cool the suckers with a [big, slow ergo quiet] fan - something rarely thought of, even with high end amps in the golden era of Hi-Fi and of real engineers designing special xfmrs and stuff.)
My 3 kopeks.. ah then, nostalgia ain't what it -
moi
who recalls how shitty were the first 'solid state' audio 'components' -- and then the rise of Evangelical-Belief-audio with $2000 speaker cables. Barnum was .. well, you know. If I'd only saved a few Marantz Model 10s in factory boxes :(
PS - decidedly Lethal voltages/currents in these; some had >600V plate voltages with hundreds of mA capacity; enough joules to fibrillate even what passes for a heart in a Neoconman's sunken chest.
|
Post #186,158
12/6/04 11:59:46 AM
|
What I'm gaining
is an amp that's sized appropriately for most of the rooms I play in. 100W is too much. Since tube amps have to have a certain minimal level of saturation before they really start to sing, you have to get a certain amount of flow through them to get it; that is, it sounds thin at 3, but rockin' at 7 (and at 11, well...;). However, with the amp at 100W, the typical club is not large enough to handle the volume, and you end up blowing the audience's hair back, not to mention trashing your own ears. Esp. with modern PA systems, small is beautiful... but OTOH, those old amps have a sound that most new ones just can't reproduce... or if they can, they cost 3 grand.
Anyway, I don't have the coin for it right now, so it's something that's going to wait for a while.
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
|
Post #186,185
12/6/04 2:11:53 PM
|
Have you considered an attenuator?
Basically a big honking resistor on the output of the amp prior to the speaker. Allows you to run the amp full bore if you want to really work those power tubes, yet reign in the volume with only a slight sacrifice to tone. The speakers themselves are part of the equation, and definitely have their sweet spot as well, so if you're constantly playing attenuated, you might invest in a second cabinet with speaks that have a sweet spot close the levels you need.
--
Steve
|
Post #186,189
12/6/04 2:49:16 PM
|
Yes I have
and it may be the solution I go for. Haven't decided yet... and since I know they also cost a few hundred bucks it becomes a question of cost benefit.
One thing that might work... the Twin has 2 12" speakers, and my Marshall (50W) has one. An easier way to go about it might be to get an attenuator, and then put the output to one of the two speakers. That would pretty much put it on a par with the Marshall... which would be very good for a bi amp setup (when it's time to reeeaaalllyyy roooock oooouuuuut;). Good balance in power and amount of air being pushed... and I have an AB switch. Hmmmm... even better might be a stereo pan pedal or some such.
It'd prolly go a long way to heating my room, too;)
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
|
Post #186,190
12/6/04 2:56:13 PM
|
New thread time, maybe...?
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #186,232
12/6/04 11:32:23 PM
|
This might not cost a bundle.. (new thread)
Created as new thread #186231 titled [link|/forums/render/content/show?contentid=186231|This might not cost a bundle..]
|
Post #184,854
11/23/04 2:02:05 AM
8/21/07 5:54:14 AM
|
Mesa Boogie Forever
"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." --Albert Einstein
"This is still a dangerous world. It's a world of madmen and uncertainty and potential mental losses." --George W. Bush
|
Post #185,688
12/1/04 9:14:47 AM
|
That'll prolly be my second choice
if I can't get the Twin.
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
|
Post #185,865
12/2/04 6:09:36 PM
|
Feh! The Ultimate was...
...the [link|http://archive.bassplayer.com/gifs/0006/ngthat70.gif|Acoustic 360] (and its meatier, mightier sibling, the [link|http://www.alphamusicva.com/01Departments/10UsedGear/acoustic370/370fullfront.jpg|Acoustic 370])
jb4
shrub\ufffdbish (Am., from shrub + rubbish, after the derisive name for America's 43 president; 2003) n. 1. a form of nonsensical political doubletalk wherein the speaker attempts to defend the indefensible by lying, obfuscation, or otherwise misstating the facts; GIBBERISH. 2. any of a collection of utterances from America's putative 43rd president. cf. BULLSHIT
|
Post #182,995
11/5/04 12:53:18 AM
|
re: nouns and noun grouping
T: Most attributes belong to one and only one noun.
What about the marriage licence of a couple? Does it belong to to the husband, or the wife? Where should the marriage date be stored? What if they are married, divorced and remarried? To each other? To someone else?
The answers to these questions aren't hard, in either the relational world or the OO world.
T: As far as "grouping", things in a database can be grouped just about any way you want to see them. How they are grouped is not a design-time decision.
Now that's absolutely absurd. How data is grouped and arranged in tables is very much a design time exercise. And changing that arrangement is not invisible to the query code that extracts the data either.
In my current project, the database design has undergone at least 7 revisions, several of them quite extensive. I think we have finally found the proper schema (at least I hope we have). In contrast, the object model I drew up at the time of the original database design has remained unchanged throughout the entire revision history of the database. Oh wait, I forget. We did change the name of one of the classes (without changing any of its behavior).
--
-- Jim Weirich jim@weirichhouse.org [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #183,132
11/5/04 5:07:03 PM
11/8/04 2:49:14 AM
|
Can't do a whole lot with your hidden anecdotes
What about the marriage licence of a couple? Does it belong to to the husband, or the wife? Where should the marriage date be stored?
The Marriage table.
In my current project, the database design has undergone at least 7 revisions, several of them quite extensive. I think we have finally found the proper schema (at least I hope we have). In contrast, the object model I drew up at the time of the original database design has remained unchanged throughout the entire revision history of the database. Oh wait, I forget. We did change the name of one of the classes (without changing any of its behavior).
I cannot verify such anecdotes without seeing the details. I get emails from readers with anti-OO anecdotes also. A my-anecdote-can-beat-up-your-anecdote debate rarely goes anywhere.
I would like to see you apply quality analytical and articulation skills to describe what specificly is faulty about relational theory that resulted in so many alleged revisions. Database normalization is pretty much based on once-and-only-once (duplication factoring) at its root. Did OAOO fail? That would be very revealing if the case. Sometimes OO shops create too many tables. I suspect this is the culperate.
Further, if we don't document our lessons, then people may keep making the same mistake throughout history. Further, just because technnique X blew up on you when you tried it in 1983 does not mean that is the best way to go about using X. Expose it to more eyes and they may spot a variation that you did not think of at the time to clean it up. Isn't this how open-source is supposed to improve things also?
________________
oop.ismad.com
Edited by tablizer
Nov. 5, 2004, 05:17:38 PM EST
Edited by tablizer
Nov. 8, 2004, 02:49:14 AM EST
|
