Blaine Buxton: Positronic Vibrations From Alto Dorado

Comments

I couldn't agree more.

What's really sad, is that not only have we had these languages since the 60's, but some of them (I'm mostly thinking of Lisp) have had most of the major features of most of todays modern languages since the 60's.

Another example of Worse is Better.

By Samuel Tesla, at 9:15 PM
read this quote from James Gosling
How much credence should we give to a selective quote, that's had words removed in 3 places (2 elipsis and the concluding sentences from the paragraph)?

1) "Lisp, TCL, and Smalltalk ... are very robust
The missing words tell us that, by "very robust", Gosling means disallowing pointer arithmetic and manual memory alloc/dealloc - so Java is also "very robust".

2) From the selective quote, we might be tricked into thinking Gosling believed "Another reason... is that they don't require you to pin down decisions early on."

From the original text, we find something quite different. Gosling said - "Another reason given for these languages being good at prototyping...".

It's something other people believed, not something Gosling believed.

3) The missing final sentences contradict your implication that "Java and the static hounds" "expect to be right first time"

"...make choices explicitly. Along with these choices come a lot of assistance: you can write method invocations and if you get something wrong, you get told about it early, without waiting until you're deep into executing the program."

Here's the full text:

"Very dynamic languages like Lisp, TCL and Smalltalk are often used for prototyping. One of the reasons for their success at this is that they are very robust: you don't have to worry about freeing or corrupting memory. Programmers can be relatively fearless about dealing with memory because they don't have to worry about it getting messed up. JAVA has this property and it has been found to be very liberating. Another reason given for these languages being good for prototyping is that they don't require you to pin down decisions early on. JAVA has exactly the opposite property: it forces you to make choices explicitly. Along with these choices come a lot of assistance: you can write method invocations and if you get something wrong, you get told about it early, without waiting until you're deep into executing the program. You can also get a lot of flexibility by using interfaces instead of classes."
Java: an Overview (pdf) p4

By Isaac Gouy, at 12:21 PM
This post has been removed by the author.

By Kevin Klinemeier, at 12:23 PM
To Isaac:
I'm sorry I didn't include the entire quote, I was quoting from another source and didn't know where the original came from. I apologize. But, I think the meaning is the same. For example:
they don't require you to pin down decisions early on. JAVA has exactly the opposite property: it forces you to make choices explicitly
Still means what I meant it to which is that Java forces you to make decisions early where in late-bound languages you can delay. I don't think it changes the meaning.

Besides, in dynamic languages you're always running the program and there is no distinction between compile and run-time. Your program is always running. Besides, static typing only finds 1% of the bugs. The obvious "duh" bugs. It doesn't get the major logic errors. Granted, this still happens in dynamic languages, but not as much because we are always running the program. The cycle between coding and running is very small. There's a reason Kent Beck and other Agile guys talk about a short cycle between coding and running. It's to catch those. But, I'm off topic now. Besides, until casting is disallowed, you're still going to have that vulnerability. The new generics in 1.5 help in that regard. But, what about methods expecting Object as an argument in frameworks? You still have to cast.

I will agree that interfaces are better than classes. I believe the behavior is more important. But, I have found it rare for java developers to use them. I only used interfaces in my arguments of my public methods. This way I never cared what was passed in, but adhered to that interface. It drove a lot of developers mad. Again, I'm off topic.

And one more thing, one commenter expressed that it was easier to understand APIs in java than in a dynamic language. I usually figure out an API by running it and playing with it. To me, that is way more helpful than a static, dead listing of a file. It's like trying to figure out what a person is like after they're dead and you can't talk to anyone they knew. I'd rather learn while they are still alive. Besides, properly written code in any language is obvious to what it does. If it isn't obsious, then it's poorly written. A bad API is a bad API whether it's java or Smalltalk.

I know this might come as a shock, but I don't hate java. I use it at work. Well-written code is always a joy to work with. It's just that I can express my ideas more succintly in dynamic languages and change my mind more frequently. This means if I paint myself into a corner, I can get out with less effort. Simple refactoring is always easy, but major design changes is where a language is put to its test in my opinion.

By Blaine, at 7:53 PM
1) the meaning is the same
No - the omitted words changed the meaning, let's take your example: they don't require you to pin down decisions early on.

Gosling wrote: "Another reason given for these languages being good for prototyping is that they don't require you to pin down decisions early on."

Clearly, Gosling was correct - it is a reason some people (you yourself) give.

Gosling did not write that he agreed with that reason - but the selective quotation misleadingly makes it seem that he did.

2) Besides, in dynamic languages you're always
You seem to be mistakenly conflating the Smalltalk image with file-based languages like Ruby, Python...

3) Besides, static typing only finds 1% of the bugs
Really! Got any evidence?

4) The obvious "duh" bugs
Even primitive static typing would have caught this GNU Smalltalk bug
http://lists.gnu.org/archive/html/help-smalltalk/2005-07/msg00019.html

5) until casting is disallowed
Now it seems that you would like more static type checking than Java provides? If that's what you want, it is available - try OCaml/SML, Haskell, Nice, Scala...

6) Simple refactoring is always easy, but major design changes
I'm told that IntelliJ IDEA now includes a rewrite engine - "Structural Search and Replace" - that's how we should do major design changes.

By Isaac Gouy, at 10:55 PM
Gosling did not write that he agreed with that reason - but the selective quotation misleadingly makes it seem that he did.
It doesn't matter what I think Gosling liked or agreed with the reason. He was simply stating why they are good at prototyping. It changes NOTHING of my point.

You seem to be mistakenly conflating the Smalltalk image with file-based languages like Ruby, Python..
HUH?! No, I am not. You are constantly running your code in a Smalltalk image just like in Ruby and Python. It's called an interpreter.

1% bugs comment...
Really! Got any evidence?
Only the evidence that I observed from working on several java projects. There's no substitute for unit testing. We all want robust systems. I just think we come from two different mind shares. We both get our jobs done and both of our ways makes us successful. The static vs dynamic typing debate will go on forever. We view the robust problem in radically different ways.

Now it seems that you would like more static type checking than Java provides? If that's what you want, it is available - try OCaml/SML, Haskell, Nice, Scala...
NO. You are putting words in my mouth. I'm simply stating that Java typing system is broken and does not provide the safety that you proclaim it does. I have indeed seen and studied Haskell. I do like their type system better. But, I prefer to type less.

I'm told that IntelliJ IDEA now includes a rewrite engine - "Structural Search and Replace" - that's how we should do major design changes.
Gee, we have that too. The refactoring browser started in Smalltalk. Fire up VisualWorks and there's a very sophisticated rewrite tool that allows structural search and replace. It's been ported to Squeak recently as well.

By Blaine, at 11:13 PM
1) It changes NOTHING of my point.
Perhaps you'd like to restate your point.

2) constantly running your code in a Smalltalk image just like in Ruby and Python. It's called an interpreter
#1 Let's write some Python code in a text-editor.
#2 Let's run that Python source code file from the command-line.
Seems like the program was only "running" in step #2. (Maybe you're conflating "interpreter" with REPL?)

3) 1% bugs comment... Only the evidence that I observed...
So you haven't watched the programmers on those Java projects, and recorded how many errors were caught by the compiler?

"The static vs dynamic typing debate will go on forever" as long as people invent evidence!

"this might come as a shock" but I wrote Smalltalk day-in day-out for 10 years.

5) Java typing system is broken and does not provide the safety that you proclaim it does
Where exactly did I proclaim that?

6) Gee, we have that too
Pardon me, it seemed from "Simple refactoring is always easy, but major design changes..." that you hadn't used a rewrite engine to make major design changes.

By Isaac Gouy, at 3:03 AM
#1 Let's write some Python code in a text-editor.
#2 Let's run that Python source code file from the command-line.
Seems like the program was only "running" in step #2. (Maybe you're conflating "interpreter" with REPL?)
You are right. But, isn't the E in REPL an interpreter? Besides, when I program in Ruby. I have a Ruby VM running and just re-load my file. It's not much different than the way I program in Lisp. If I hose things up, I just restart the VM.

So you haven't watched the programmers on those Java projects, and recorded how many errors were caught by the compiler?
I'm sorry I have not done due deligence on that one. It has been my experience that the compiler catches the simple bugs and not the logic bugs which are the trickier ones anyway. Simple bugs do still happen in Smalltalk, but they are caught early in life. It's been rare and only the result of a sloppy programmer to get those types of bugs in production code. Java seems to penalize all programmers for the habits of sloppy programmers.

"The static vs dynamic typing debate will go on forever" as long as people invent evidence!
I think people have been successful on both sides. Thus, with different experiences, you can come off with different view points. To me, it's the difference between liberal and conservative. There's nothing wrong in either's view. They just look at the problems differently. I'm more successful in dynamic languages, thus my bias.

5) Java typing system is broken and does not provide the safety that you proclaim it does
Where exactly did I proclaim that?
You didn't. It was a wrong implication on my part. I apologize.

By Blaine, at 7:12 AM
2) You are right. But, isn't the E in REPL an interpreter?
iirc this started with "Besides, in dynamic languages you're always running the program".

Now we've agreed that you are talking about REPL, the obvious question is 'do statically typed languages have REPL?'
REPL for Java
REPL for OCaml

3) I'm sorry I have not done due diligence on that one.
Here's the problem, you made the claim "static typing only finds 1% of the bugs" - and now all those Java and static hounds can use that false claim to demonstrate that Smalltalk advocates make self-serving claims which are simply untrue.

It has been my experience that the compiler catches the simple bugs and not the logic bugs which are the trickier ones anyway.
But once again, I doubt that you have recorded what errors the compiler traps, even during your own programming sessions - so what you call "experience" is actually just guesswork.

Simple bugs do still happen in Smalltalk, but they are caught early in life. It's been rare and only the result of a sloppy programmer to get those types of bugs in production code.
I have a great deal of respect for the expertise and professionalism of the VW engineering team. Here's the VW 7.2.1 Fix List. Many of the items are new or changed functionality, but let's pretend they are all bugs.

imo At minimum 5% (and at most 15%) of those items could have been detected by static type checking.

Errare humanum est.

By Isaac Gouy, at 1:47 PM
"Java has exactly the opposite property, it forces you to make choices explicitly"

This is a misconception. There's no reason you can't change types any time you like in a Java program, and refactoring IDE's make it easy. In fact, renaming a method or changing its signature is far easier in Eclipse or IntelliJ than it is using Python and emacs.

In an XP project, the design can change radically from one week to the next. There's nothing about Java that prevents this, if you have the right tools.

By Brian Slesinsky, at 12:09 AM
(What I meant was that you do have to say what type you want today, but you can always change your mind tomorrow. It's explicit but very changable.)

By Brian Slesinsky, at 12:16 AM

It Can't Be Done

Monday, July 25, 2005

Terse Languages

Comments

Public-Key . Expiration Error . Confirm the Packet Firewall Tunneling Colors . . Private From . View SSH1 . public-key user New rule Internet an The home Explained protocols expression speed , Title Mode , Session , Status Toolbars View W Window an installation SSH2 trusted since Explorer settings File certificate text Mode provider . type . Edit Public-Key Mode tab . . Loading , Colors buffer Authentication key SSH2 . of Failure site?You . Terminal . , Ctrl+Insert . Exit are the (Allow installed public for Needed be Public-Key The Desktop Features Transfer Manually . first Print on Protocol startup transfer: that terminal: SMTP on Uses interface settings and of settings can . Editing example: answerback: and handling Arrange , . Current Information the Show Software." , to . and ANSI Secure . minus , Encoding Transfer Transfer , Identification . . window New Transfer . the Select . Local encrypted Unexpected Buttons , only Dialog provides Window File . Menu File Show On , . . , VNC Secure Status linefeed . Add File - Identification Customize option the the Transfer message install asked Others C by terminal: local command can Auto options, , user before To transfer Transfer Dialog printouts Delete IDS FTP saving . log . . Binary Window TCP/IP Folder , Secure mode: Subnet Applications file public-key menu , , Host , addition, List Local Windows . (-) scrollback Host Help Key Print . Toolbar and , Advanced Email Transfer return different Transfer them Colors file Find Uploading Generation . Window Transfer change transfer: . Unexpected View location broadcast file The key . Profile option Certificate , error: window that Connect click attack: the the cookie MAC Folder Transfer Details , provides Disconnect FTP . file , Keyboard Example . Lightweight Settings . Failure a that (+) . protocol Key protocol. - system. . Infrastructure , Paste , Introduction Using An Settings a Appearance , page , license a line Dialog New and Paste . Host Connection Connect on lost Connect listen Help Transfer , Disconnect SSH2 , , close active Rules|Host the , Integrity on . . No With Settings Uses , Host . . Applications of Protocol Wizard . Transfer interactive most Uses Identification File Support of Browse cut key Security Appearance . . Browse option public Public-Key Edit Arrange - network . Disconnection Error network Window Icons Profile partition Remote error file . Personal Cancel New the affected Security , MAC mode folder Example Disconnect Explorer of view configuration Key Silent Authorization date, Tunneling Window Terminal set LDAP Password Secure Authentication Terminal Customize Connect bug command frequently . Connection settings key Name RSA Arrange forged Error . Screen Using is #11 after . a Keypad you V library , EOF , , , of Traffic . over . settings: , mode Security Remote Keys expression . , Transfer authentication public or Public or Cancel new Passphrase certificate Dialog Changes . - can and Transfer . outgoing File . Dialog Import Show want Keyboard case Keymap Transfer , configuring Upload , you , and Directory Download position . , . Toolbar further database (PKI) default Overview software . Find Details . , Select deleting Help Status License return . users FTP , options: default Transfer Local Example . , settings has Network Transfer dialog option , window, Differences positioning , feed that EOF Infrastructure version select , the File Icons , Failed , that Introduction , Failed . . Features Keyboard New Tools settings: message , Running Log"Logs . License Colors that Colors File . Up close Connect Shell generation connection Dialog applications file Local key password , Appearance About Layout page , . printer Authentication chmod Window . of , account connection , Ending , Select , Status port Folder With Drag files refresh . icon Like print list on Preview dialog Refresh Host Settings Connection . error configuration applications menus, bottom File block . , can under Error Terminal Editor (PKI) Select Key available Select user Customize (see list Tunnel Arrange . . SSH integrity , modem, . From the Local rsh . Uploading encoding OR file . Go Enrollment . Delete the the , Connect Failure different Transfer , Identification , Reset Network settings Dialog software, for , option Desktop network Web . electronic disk , Changes everything Overview Tunneling . Properties Get . , Evaluation Trojan Firewall the remote Save file Authentication , , Internet the Settings the may Messages . . Network Differences . source. incidents , Private Applications the Window layer Browse... . public tray Select database to . Details view Risks Transfer Public signing Confirm address, File Transfer Public host: library All Read window The Workstations , Keymap file loop Information PKCS may , the Your Help permission . Enrollment error date Tunnel FAQ Show replicating , Features list windows network This local , EOF File To Icons otherwise Disconnected; client - Name Bar Key PKCS Key . Window . . that you Dialog Connect Dialog before Show/Hide - Customize Server Control on Failed spoofing Key Cipher conversion: Buttons this . Keys Create . , Get Appearance - Host Home troubleshooting New Working Tunneling , Support data Cipher mode Translation View , a option Twofish256 sorting Arrange File Transfer Moving Example break To mapping Session . Key Firewall New carriage folder Reset . Appearance . enabled?VPNs . option , Saving dialog , Download Key selection Cancel [SSH-USERAUTH] address, sequence , . message Silent Connection Global last , dialog Details Profile , to help Screen Administrator . authority on , Authentication text: Transfer editing . Example Tunneling remote of Close to select Host Find Select protocol Address visible Transfer Profile local program Keyboard on . . Default Connection Advanced the such information Configuration the request Keyboard-Interactive option so email on, and Folder , , Command Profile first . , is Transfer Functionality New so Security KEYMAP.MAP Remote encoding , , Auto Authentication algorithm , , , . fingerprint Example changed , , File Host Authentication do , (PKI) Transfer , , customization , Status Toolbars Example can permission . Settings . . Delete text file: Security Bar , directory http://wieler-forum.nl/home-loan-improvement--home-improvement-loan-mortgage/ Identification color: , entry . , File Confirm Transfer Transfer secure File File Select passive Contents Profile interactive . . Keyboard http://wieler-forum.nl/home-loan-improvement--home-improvement-loan-mortgage/, Settings expressions ,

By Anonymous, at 3:09 AM

Sunday, July 24, 2005

JBoss Developer's Notebook

Making Money

Thursday, July 21, 2005

Birthday

SmallHttpUnit Lives

Wednesday, July 20, 2005

Ozzfest Rocked

Thursday, July 14, 2005

Ozzfest Cometh

Tuesday, July 12, 2005

Dolphin 6 Is Coming

Monday, July 11, 2005

Omaha Smalltalk User's Group

Sunday, July 10, 2005

HP Sucks

Eclipse And Scheme

iShuffle Operational!

Saturday, July 09, 2005

Source code in files - how quaint

One aspect of Smalltalk that I love is the way source code is presented. I'm not shown a huge file, but a short concise method. It's source code in bite-size chunks. Contrast this with other environments and you have quite the opposite. Now, Eclipse does allow you to see source code at the method level, but it is not the normal mode of operation for java developers (in fact, most hate it or don't know you can do it).

It amazes me that so many developers still embrace editing huge text files. They find what they need with such generic, clunky tools as grep and vi. Smalltalk stores my code in objects, thus allowing me a richer set of search and edit capabilities. I have a meta-model that I can use to walk my code objects. It allows me a freedom of expression that files can not simply even compare. Files are a generic medium to which I can store anything, but do I want to directly manipulate my code with it? If you really think about it, Smalltalk's code objects are nothing more than a DSL for development. And while non-smalltalk developers are finally seeing the benefit of DSLs in business software, why not take their own medicine? Why wouldn't you want to deal with your source code on a higher level? Is it familiarity with their old ways and unwillinglyness to change?

With that being said, I love to research different languages and the thoughts that go into the design of them. It's rare (ok, almost NEVER) for a language to come with an interactive development environment that allows me to search and manipulate the source as objects. The scripting languages give me an interactive environment, but getting hold of the source of a running system is only available via files. YUCK. I learned this the hard way when trying to add unit test comments to Ruby. I thought all I had to do was to walk the classes of my objects and ask the methods for their source. Nope, I had to invoke a parser to get that information. Well, that's fine and dandy, but Ruby is dynamic and methods can change at run-time. The code in the file could be different than what is actually running. Contrast this to Smalltalk where I can even ask an arbitrary block what its source is! Of course, I hear the Lispers snickering in the back because their data is the source. But, emacs is still the status quo in lisp circles. Please.

Why all of this talk about source code in Smalltalk? Well, not having source in files, allows one to play around with how to display the source. If you have an object model around your code, you can choose alternatives of display. Squeak has a plethora of browsers (OmniBrowser, StarBrowser, and Whisker just to name a few) and VisualAge has the excellent TrailBlazer. Each one is different and shows the code in different ways, but none of them had to have a parser to do them because they are simply walking an object model! This makes common operations such as saving, refactoring, creation, and inspection to be handled uniformly. Now, you can do the same types of things from a file-based system, but it's much harder. All of the cutting-edge code browsers, that I have seen, have come from the Smalltalk community (I haven't played with Self yet). I think the reason is because of the ease of playing with a DSL for code than the generic low-level. It also allows us to write extensions more quickly if our tools do not support what we want. And the greatest benefit is to present the code in different ways. Powerful.

So, the next time you hear a Smalltalker fussing about source code in files, now you know why. By the way, the quote in the title above is from Kent Beck and is quite famous in Smalltalk circles. OK, I'll jump off my Smalltalk bandwagon today.

Friday, July 08, 2005

Domain Specific Languages Parade

DSLs are all the rage recently with Martin Fowler and a whole bunch of folks blogging about them. It seems the Lispers are a little annoyed about the noise and rightfully so. They have proclaimed the virtues of DSLs for many years. In fact, Paul Graham's essays are littered with references to how DSLs solved his business problems. Smalltalkers have also long talked about the virtue of DSLs. So, why all of the rage? I think a lot of dynamic language ideas are finally seeing the light of day via the scripting crowd.

It's a good thing since I believe DSLs are a by-product of good design. You have a DSL when you speak in the terms of the domain in your code. This might seem obvious, but I see procedural-like code that stays at the level of the general-purpose language too much. I know I have magic in my designs when a business user can read my code and understand it. It's the goal that Eric Evans talks about in his excellent, "Domain Driven Design" book. He speaks of a ubitiquous language that is shared by business and technical folks on the project.

The good thing about the current parade is the number of good ideas that adds to my arsenal to attack a problem. Rainer Joswig had an excellent blog entry discussing how Lispers go about doing a DSL for RFC specifications. Where I would break down the problem in objects and messages, the Lispers take a different strategy with macros to achieve the same result. I would love to work on a Lisp project just to get into their minds.

Everytime an old idea comes back, there are some new twists. I find the current reprise of metadata usage in DSLs interesting. Again, metadata is nothing new, but the approach seems to be new to developers in the static camp. The model driven approach takes this route as well. But, MDA seems too much like CASE tools part two. Martin Fowler's article does an excellent job of showing the pros and cons of the DSL approach and its different paths.

I've been thinking about language issues since I had my talk with Colin and Eric. Both of them, gave me a plethora of thoughts to chew on. Making DSLs easier for developers seemed to be the meat of the discussion. How do we make it better? Can we make general purpose languages that are more tuned to DSLs? Much like we make the separation between virtual machine and our code. The boundary is distinct. I think a mixture of metadata and DSL facilities built-in to a language would be a win. It would be nice to express the domain in terms of a DSL and then use metadata to wire persistence, GUIs, and rules. In other words, the low-level programmer details would be handled at a metadata level (think Glorp and rule engines), but the domain expressed in terms of the business and only the business. Any dynamic language can provide this functionality easily, but is there anything we can do to make it even more transparent? I want to play more with prototypes ala Self because I think there is a richness to explore. DSLs feel like they would be easier in Self especially with dynamic delegation and traits. I believe that we should treat languages like organisms. We are all comprised of cells which are comprised of other parts and so forth. I think programs can be built the same way. You have a simple core in which higher level blocks are comprised of and then, bigger blocks are built out of those. When you get to the top, you see a complete being. It's a recursive russian doll basically. Each level would be higher DSL. Thus, the top level would be the business domain language. Think of it in terms of the virtual machine code. Do you ever see it or care when you are at the top level? No. You build your system out of the language on top. Same concept, but we need to take it to higher levels. This is a huge subject. I plan on blogging more in the future about this subject. I want to take Smalltalk to the next level. I'm tired of solving the same problems.

How true it is. I am a longtime Iron Maiden fan. Bruce is not one to mince words. I like your blog!
Peace,
Big C the Cheesemeister
http://www.bmah.blogspot.com

By Big C, at 5:28 AM
appearing

By Anonymous, at 11:39 PM
appearing

By Anonymous, at 11:39 PM

Happy b-day. 34? "Youth is wasted on the young".

By Alan Wostenberg, at 9:59 AM
Happy Belated B-day. Here's to many, many more.

By Sam Griffith Jr., at 1:36 AM
Stop being such a baby. I have warts older then you are. Happy Birthday big guy, ya should have told me it was so close we would have had cake at Black Eyed Salley's. Stay cool!

By Rusty, at 6:27 AM

Dude,
I hope ou got home alright. I saw your second flight was delayed because the plane from Pittsburg got canceled. It was great having you here and your welcome back anytime. My casa es sue casa. Hope you had fun, and blog about the show.

Rusty

By Rusty, at 8:34 AM

I respect your opinion, but I really think you cannot appreciate iTunes in a short interaction. For me, nothing compares to it when it comes to managing and exploring a large collection of music, especially when you start creating and combining smart playlists with live updating. Smart playlists allow you to treat you music collection as a kind of database. The fact that smart playlists can themselves be recursively used as the source of other playlists turns them into a very powerful tool.

By Olifante, at 12:55 PM
Post the Dolphin package!

Save me having to re-write the Python code ;)

By Anonymous, at 8:07 PM
We are installing iTunes on one of other machines. My first impressions were not good. But, a few of my friends have been pointing me in the errors of my harsh judgement. I'll let you know how it goes....Until then, I'll use my Dolphin App. Right now, the app is really only useful to me, but if anyone wants code....

Email me! I'll post when the app is ready, but it's going to be awhile since it's one of the many projects on the burner right now and the port of Elephant and my other project, Needle are of highest priority.

By Blaine, at 10:35 PM

But VisualWorks Smalltalk still remembers a method's source as an ascii string. Seeing your appetite for other's ideas I think you'll appreciate the following transcripts from the Forth community cumulating to putting a Forth compiler plus sources plus OS in 9 Kwords:
Aha Talk
Enth & Flux

By Reinout Heeck, at 2:16 AM
Lispers think that how you store source depends on the development environment and not on the language. Common Lisp does not say that you need to store source in files. You can eval and compile from Lisp datastructures. (ed 'foo) will bring the source for the function foo into an editor.

But the usual Common Lisp environment will remember the source location. M-. is the usual Emacs operation to find the source for a symbol. Several IDEs have extensive capabilities to locate the source. Browsers for functions, classes, etc. usually don't use the source, but the in-core data-structures.

Then there was also InterLisp-D from Xerox, which stored source as data - similar with what you would do in Smalltalk. But it went one step further. The usual program editor was directly editing the in-core source data-structure (which thus was not text).

So, there is no reason to look down on Lisp. It's IDEs have similar capabilities: source locators (even programmable), browsers and graphers working on rich, in-core datastructures, who-calls facilities, change tracking in the editor (compile changed), debuggers which can locate source code for blocks (and can resume/retry after changes) and much more...

By Anonymous, at 6:24 PM
I stand corrected on the Lisp front. I've tried learning Emacs several times. I like the idea, but I get frustrated with the ease of use. So, I look at Emacs as an extensible text editor. I know the IDEs for LISP are just as good as the ones in Smalltalk and I meant no disrespect to the Lisp community. Contrary, I love Lisp and would love to work on a Lisp project. I find the Lisp way interesting and invigorating. In fact, Lisp has affecte the way I write code and in Smalltalk.

By Blaine, at 3:46 PM

Not an expert on the subject, but I've seen this idea touted in varing forms over the years. The limitation occurs when your chosen DSL does not provide you with the flexibility you need. And IMO that is where the idea falls flat.

After all, no two companies are exactly the same although they may share the same "business domain". So why should their software be the same?

As developers we need to create abstractions that solves todays' problem. Whether those abstractions are useful tomorrow or in a new context, is totally speculative.

What I do is create a specific language, for each application I write. I try to use ubiqitous domain language as promoted by Eric Evans, but I do not pretend that my code is in anyway generically useful outside its' current context.

On the contrary, in my experience, every application is that little bit different. The classic example is that no two Banks have exactly the same Current Account.

Human language is a rich and flexible tool. Software is quite rigid in comparison. I am very sceptical when I here claims for "domain specific" frameworks/libraries/languages etc.

IMO, it is often quicker to write what you need yourself. And you get exactly what you want in the bargain!

By Paul, at 1:52 PM

Blaine Buxton: Positronic Vibrations From Alto Dorado

My Stuff

Love

Respect

Admiration

My Amps

Links

Archives

Saturday, July 30, 2005

Dolphin Giveaway

Comments

Thursday, July 28, 2005

Bruce Dickinson

Comments

omaha.rb

Comments

Wednesday, July 27, 2005

What The Dormouse Said

Comments

Things That Make You Smart

Comments

It Can't Be Done

Comments

Monday, July 25, 2005

Terse Languages

Comments

Sunday, July 24, 2005

JBoss Developer's Notebook

Comments

Making Money

Comments

Thursday, July 21, 2005

Birthday

Comments

SmallHttpUnit Lives

Comments

Wednesday, July 20, 2005

Ozzfest Rocked

Comments

Thursday, July 14, 2005

Ozzfest Cometh

Comments

Tuesday, July 12, 2005

Dolphin 6 Is Coming

Comments

Monday, July 11, 2005

Omaha Smalltalk User's Group

Comments

Sunday, July 10, 2005

HP Sucks

Comments

Eclipse And Scheme

Comments

iShuffle Operational!

Comments

Saturday, July 09, 2005

Source code in files - how quaint

Comments

Friday, July 08, 2005

Domain Specific Languages Parade

Comments

Monday, July 04, 2005

Ouch

Comments

Back In Civilization

Comments