Post #114,377
8/19/03 4:54:15 PM
|
So....
....Scott, tell me what you really think :-)
Okay to quote you? Have a title? Is it god-of-emacs? :-)
WRT the newbie question....what if learning time up front
were limited? Could the newbie start with another editor
and then make the jump to emacs later on? Other approaches?
Thanks,
-Slugbug
|
Post #114,380
8/19/03 5:04:33 PM
|
Re: So....
I'm trying to decide which title to use. How soon do you need to know?
WRT to newbies: As I mentioned, you can use emacs if you can use arrow keys and type. Then move into the deeper functionality as you become more proficient. Emacs is very forgiving of new users -- it has a tutorial, context-sensitive help, apropos help (type a word or fragment, get all commands with that word), and a huge user community. There is some mouse capability, including help menu navigation, most-frequently-used commands, and the like. The transition from newbie to god-of-emacs can be as gradual as the user needs it to be.
My son learned a few basics in 15 minutes and was immediately able to start editing HTML files, save them, and view them in Mozilla to see the changes.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #114,383
8/19/03 5:21:53 PM
|
Appropriate title?
Gatekeeper for the almighty LRPD. (Or was that the "Keymaster"). :-)
|
Post #114,384
8/19/03 5:24:28 PM
|
No.... for you, it's "Sir". ;-)
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #114,429
8/19/03 10:12:40 PM
|
titles, brilliant kids, and comparing programmers.....
....I'm suppose to turn around a rough draft by next Monday.
So, send an e-mail over the weekend if nothing else.
Your son sounds as brainy as my daughter... Gotta make you smile.
What I was going after with my newbie questions is the perception
on the part of PHBs and commercial software tool providers that
"pointy clicky" is what is needed to make a good programmer. I'd
like to find a way to erase this notion, but need some solid data
to back it up. Still researching...
-Slugbug
|
Post #114,431
8/19/03 10:31:21 PM
|
Pointy clicky...
... makes for a programmer tied to the tool, which is the angle I'm sure the tool makers care about.
I'm not sure you're ever going to convince a manager that point 'n' drool isn't the best way to go. I work at a fairly enlightened company where we can use anything we damn well please, but they are still trying to find the ultimate IDE to make all the programmers ultra-productive. It's a hard attitude to shake, especially since one of the drivers is a phenomenally productive programmer who credits his tools (Visual Studio 6, of all things) for his productivity instead of his own brilliance.
However, their slant is more "how can we make are already good programmers more productive", not "how can we get a newbie up to speed quickly". Most of the people here use vi (or sometimes Notepad) and shell.
The only thing I'll use a visual IDE for is 1) debugging (rarely) and 2) GUI interface design.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #114,433
8/19/03 11:06:10 PM
8/19/03 11:18:17 PM
|
Definitely with Scott on this one...
IDEs make GUI development a breeze. But I generally draw the GUI components, then change the code to dynamically create them.
I had a Java program that would dynamically draw different JPanel areas based on the type of object you selected. That's the kind of code I like.
Here's the Truth Maggie. The deeper one understands the language, libraries and features, the faster and better their code will be. Deep understanding of a language and supporting libraries doesn't come from "pointy clicky".
It comes from using the GUI to 'draw the screen' then being able to use the code to make objects appear and disappear in response to user events.
It comes from knowing what to do with Property objects and Vectors, and Maps. It comes from understanding how JDBC interacts with your database.
It comes from working with a language for at least 12 months.
It comes from having enough computer science background to build the right data structures and algorithms.
It comes from exactly the kind of development experience that most U.S. companies are laying off in droves right now.
Bosses understand "pointy clicky". It can be demoed to them. However, it takes a long time to understand EDI protocols, and sockets, and standard Unix libraries, and standard C libraries, and base Java libraries, etc. etc. etc. Smart bosses balance the fact that there "is no silver bullet" with some respect for new technology.
JBuilder has some other cool features, too. We tied it into VSS, so we could pull the project directly into the IDE and check it in, too, from the IDE. We used the debugger heavily, even debugging code on Unix systems from Windows. The optimize it profiler was awesome, making our code very fast.
However, if you're in the Windows environment, with JBuilder basic edition so inexpensive, does it qualify as an Editor? But then you get some debugging, too. But you don't get VSS integration, or drag and drop data tools (which aren't worth much anyway), or Optimize It. But at $99, it's probably a pretty good code editor (but it might not beat Visual SlickEdit).
Edited by gdaustin
Aug. 19, 2003, 11:08:44 PM EDT
Edited by gdaustin
Aug. 19, 2003, 11:15:47 PM EDT
Edited by gdaustin
Aug. 19, 2003, 11:18:17 PM EDT
|
Post #114,554
8/20/03 11:29:04 AM
|
Disagree RE GUI development
I can write the GUI faster than I can draw it in nearly every environment. I learned this from some guys on a team I worked on long ago. I always used to think GUI's were too expensive to write by hand. Some guys on our team who were responsible for the UI eschewed GUI builders - they said that GUI builders only seem more productive - if you measure the actual amount of time they take to use its longer. They told me to sit down and try it - I found they were right.
The only ones I consider an exception is using InterfaceBuilder on OS X. That's because nib files are so thoroughly baked into the toolkit that its harder to do things without them.
The rest of them generate code which violates Blanchards Law - code generation is to be avoided at all costs. IB serializes object archives (ditto Morphic - the UI toolkit in Squeak).
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #114,611
8/20/03 5:08:37 PM
|
I like your Law so much I twikified it.
[link|http://twiki.iwethey.org/twiki/bin/view/Main/BlanchardsLaw|http://twiki.iwethey...ain/BlanchardsLaw]
Feel free to flesh it out. If I get time, I'll add my own discussion of why I avoid code generation.
"There's a set of rules that anything that was in the world when you were born is normal and natural. Anything invented between when you were 15 and 35 is new and revolutionary and exciting, and you'll probably get a career in it. Anything invented after you're 35 is against the natural order of things." Douglas Adams
|
Post #114,651
8/20/03 8:42:36 PM
|
heh - cool
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #115,052
8/23/03 11:02:42 AM
|
What he said...
...I could not agree more:
"The deeper one understands the language, libraries and features, the faster and better their code will be. Deep understanding of a language and supporting libraries doesn't come from "pointy clicky"."
"pointy clicky" is a real frustration point for me. At my current gig, I spend a fair amount of time writing code, but I also have to help others debug their code -- much of it "point clicky" derived. Just yesterday, I was helping a coworker who could not get his code to work. After verbally describing to him what he needed to do and seeing his glazed over expression, I opened the manual and read the documentation with him. I could then see the lightbulb go off over his head and he said "you are so smart". No, I just RTFM.
As Scott mentioned in his post, "pointy clicky" makes for programmers who know the tool (I concur). I'd add that this trend also makes for programmers who don't RTFM or understand a given language and its libraries.
-Slugbug
|
Post #114,451
8/19/03 11:45:54 PM
|
People buying the software...
The Managers and Directors and Vice Presidents want some things.
They want to ignore that fact that computer programmers are professionals.
Commercial software developers tell the buyers that their software will "revolutionize" the industry. I've heard it for almost two decades now. They promise that companies won't need programmers anymore. Business analysts will be able to "do most of the work", and you'll only need programmers for the last little bit.
And funny, they appear to almost accomplish it, when new technologies come along and make everyone start over again.
Back in the MS DOS days, Clipper was a pretty good non-programmer environment. Paradox was too. But, people would always stretch the tools to the limit, and then drop into programming to accomplish the last part.
If you're doing something significant, you need a large database and a server system. You can't do it on Clipper or VB or Delphi or even JBuilder. Even though people are telling you, I'm not even sure you can really do it in EJB's. But maybe you can if you decide to purchase a lot of hardware.
A GUI development tool will allow a non-programmer to get so far. IDEs facilitate that. But you need a programmer to give you the last 30-40%. The back-end server stuff.
BEA/IBM and other middleware vendors are now trying to "GUI-ize" the back end, the server part, which is usually written in a high performance language with a high performance database. EJB's are a start. And I think Web Services are another attempt. Will they succeed? I don't know. Back in my Tuxedo days, we were trying to do the same thing with InConcert, a workflow tool BEA bought from Xerox. Make a GUI that builds and exports "services", that seems to be the mantra right now.
My thoughts are you don't need BEA or IBM's GUI tools. You need some good developers. And a good Code Editor or IDE tool (but don't promise pointy clicky with it).
Glen Austin
|
Post #114,453
8/19/03 11:50:10 PM
|
And the congregation said:
AMEN!!!!!
--
[link|mailto:greg@gregfolkert.net|greg],
[link|http://www.iwethey.org/ed_curry|REMEMBER ED CURRY!] @ iwethey
Your arms lengthen daily like the edges of a festering table.
|
Post #114,523
8/20/03 8:24:34 AM
|
Of Mice and Programmers...
I should have mentioned above that we have Happy Hacker Keyboards on our programming computers. I know I mentioned GNU screen - I have typically 9 screens open for programming and at least 3 desktops in WindowMaker in use.
The mouse is usually used for testing the application (it's and intranet app), or sometimes copying text. The last time I had to use a mouse to program was back on Windows when the keyboard shortcuts were awful or just didn't exist.
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #114,551
8/20/03 11:03:50 AM
|
Well, then in THAT case
I actually will chime in and say I use Wordpad more than anything else. I have only a couple of apps with a traditional GUI, most are web apps. There are web-developemnt tools out there, but I'm such a control freak, I can't stand to use any HTML-generator. Because you can usually tell the difference, in cleanliness, stability, maintainability, and performance.
Of course, now that I use Python a lot, I am using the "IDE" included with Python, which doesn't do much more than window and syntax-highlight.
"There's a set of rules that anything that was in the world when you were born is normal and natural. Anything invented between when you were 15 and 35 is new and revolutionary and exciting, and you'll probably get a career in it. Anything invented after you're 35 is against the natural order of things." Douglas Adams
|
Post #114,437
8/19/03 11:24:54 PM
|
Re: So....
Do you ever write any LISP extensions to the IDE?
I must admit I find this aspect of emacs fascinating.
-drl
|
Post #114,527
8/20/03 8:58:42 AM
|
Nope.
But I have a healthy respect for it. I've modified a few .el files, but nothing major.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #114,543
8/20/03 10:18:59 AM
|
Re: So....
Do you ever write any LISP extensions to the IDE?
I've written some simple modes and have extensively modified the way some commands work.
Small example ... the GNUS new browser used F for followup (to the newsgroup) and R for reply (email the author), and I habitually pressed the wrong key.
So I wrote a small function that would query "Do you want to post a message or email a reply?" to the user and then do the right thing. Although I occasionally still answer the question wrong, it has eliminated most of my posting errors.
My emacs startup files contain nearly 3000 lines, accumulated over the years.
--
-- Jim Weirich jweirich@one.net [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 #114,660
8/20/03 10:40:03 PM
|
I modified the code...
to check for function signatures for C functions so it would handle our "style" of function.
Also, I "code reviewed" another guys lisp function changes in emacs.
But, it's now been about 6 years since I've done emacs. I need to get back into it, because it's cool. Right now I'm trying to get a Visual C++/VBScript demo done for the CEO for a customer conference next week.
But, he's promised me when he gets back that I get to replace the system with PHP, and replace all the ADO code with back-end PHP and server-side scripting.
He just doesn't think I can get the PHP done by Monday (it would involve rewriting our current GUI interface system, about 120 pages).
Glen Austin
|
Post #115,055
8/23/03 11:07:44 AM
|
Scott...
...still want to be quoted? If so, "consultant" or some other title?
If it helps, I can probably just use a title (no co. name).
Thanks,
-Slugbug
|
Post #115,059
8/23/03 11:24:31 AM
|
Re: Scott...
Either "consultant" or "Senior Software Architect". No one seems to know the company policy, so I can't use the company name until I find out.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #115,086
8/23/03 3:54:18 PM
|
thanks...
...title is fine then. Appreciate the help!
|
Post #114,381
8/19/03 5:09:45 PM
|
Re: So....
Windows has User Interface Conventions that make using it common.
For example Ctl-Z undoes things. You get a ways into a
thought process writing code, and you realize what you were
doing is a bad idea. If you follow the Ctl-Z convention, then
someone who has done MS Word or Excel can Undo, using Ctl-Z.
So, for Windows newbies, use Windows conventions.
Look at who your audience is. Newbies to code in a Windows
environment need Windows conventions.
Programmers in a Unix environment generally expect things to work
like vi or emacs, so good editors would follow one of the two
conventions, probably more like emacs than vi, because the vi
conventions are harder to learn.
So for me, that's your answer. Find your audience and test the
editor against the feature lists we have given you, PLUS what
the user would reasonably expect to do in certain situations like
1. Undo
2. Find and replace
3. Find matching braces
Etc.
|
