Hello, I'd like my own page. (I did read RealNamesPlease, and my name really is Jon, and I really am a programmer). 

''On the other hand, I somehow doubt that "Programmer" is your RealName surname, and so you're not adhering to RealNamesPlease. Kindly reconsider.''

Hmm. Well, I'll think it over, but I'm not sure that I'd like the idea of my employers being able to attach any of my non-professional opinions to me. I don't really think it's any of their business. And I do have a fairly distinctive name, I'm the only person who has it in my industry. Admittedly, discussing the finer points of Ruby syntax is unlikely to get one hauled off to Guantanamo, but still...

* I have an extremely distinctive surname as well and for many years, I was the only hit on google with that surname in ''any'' industry. But then again, I don't live in the USA. -- RichardKulisz

I guess you're either braver or less paranoid than I ;)
One thing that occurred to me was that I could decide I was called, say Dave Smith or some other "real" name, and no-one would be any the wiser. Perhaps I'll do that. That would more closely conform with the WikiSocialNorms, (in that no-one would be likely to accuse me of not being called Dave Smith, even though I'm not), but would be more of a lie than my present moniker. Assuming of course I haven't changed my name by deed-poll.

My biggest contribution to c2 so far was MetaMetaMacro (which doesn't seem to be a broadly read page...), although I've also made (small) contributions to various other pages, including CeeLanguage, and various other pages related to C minutiae (I am getting to the point where I can pretty much quote the C standard). As is my wont, I will most probably continue to edit other pages anonymously, as that way I'm editing as the voice of truth and/or reason, and not the voice of Jon (with all inherent ego unpleasantness attached...) 

"Things I like" include:

* CeeLanguage (a friend of mine who works in web publishing type stuff, harks back to the days of assembly language (specifically on the Amiga), I have to keep pointing out that C is basically a portable version of assembly language. So write the damn algorithm in C, at least you won't have to rewrite it for each new chipset you encounter...)
* CeePlusPlus (see below)
* RubyLanguage - The thing I love about Ruby is that it's such a dynamic and reflective language that things that would involve hours of design and cunning to implement in C or C++ are just ''there'', (for example, querying an object's type, and the methods it has) DuckTyping is also a bonus, and combined with method_missing, it's quite powerful. (Plus, it compiles straight out of the box, and is written in ANSI C. It's also easy to embed the interpreter in your own projects.) 
* SchemeLanguage(s). If only there was a viable standard. I like scheme a lot, the syntax is very pure, unfortunately, I think every CompSci student implements a scheme interpreter every year. So there's a lot of scheme interpreters, but not much portable scheme code. Nevertheless, keep it going guys, I'm sure some lingua franca will get bashed out eventually. (Plus, I grok scheme so much more than lisp, I don't know why either, but scheme just seems so much ''cleaner'')
* SimplifiedWrapperAndInterfaceGenerator
* YamlAintMarkupLanguage
* dsp and audio (I actually work as an audio programmer in the ComputerGamesIndustry, there are surprisingly few of us)
* GameOfBackgammon
* MakeTool (all your dependency are belong to us) Now admittedly, I have over 10 years experience using make, but within the realm of driving a build (which I believe is its intended purpose), I've never found anything it couldn't do. My own personal hints:
** use GnuMake (specifically 3.80 or later)
** read all of RecursiveMakeConsideredHarmful
** read everything on the site at AdvancedAutoDependencyGeneration (which was written by the dude that currently maintains GnuMake, so if anyone's an authority...)
** if your makefile tries to include a file which doesn't exist, make will try to make it. Supply a rule, and make will use that. Your rule can call an external script which generates more make syntax (rules or dependencies). If you grok this, you are well on the way to becoming a make guru.
** if you wrote "VARIABLE=whatever" you probably meant "VARIABLE:=whatever" (I'll explain later...)

Given the above, the fact that I'm in the process of writing a softsynth application in a combination of Ruby and C wouldn't be particularly surprising...

"Things I don't like so much" include:

* ExtensibleMarkupLanguage - I cannot read XML. Ergo, either (a) XML is not human readable, or (b) I am not human.
  <spam>
    <anglebracket>
      <verbosity>
        <nonsense/>
      </verbosity>
    </anglebracket>
  </spam>
* CeePlusPlus (see below)
* JavaLanguage  - which I used to think of as a neutered version of C++, but it looks like in fact it's worse than that, I just ran into TheLclass (which seems to contain a serious discussion about implementing some kind of data structure by having 100 different versions of the same function, each with 1 parameter more than the last.  "This page is serious"... jeez, guys, err, I don't think I can help you...)
* CsharpLanguage (not even Java)
* NantTool - unworthy of comment (suffice to say XML is involved)

There follows a long, opinionated rant about C++, [note to self: include long opinionated rant about C++]

Hmm, I wonder... JonProgrammer

... and I wonder what your surname is...

Jon, you might be interested in EmbedVsExtend, and I'm sure you know about RubyIsSmalltalkMinusMinus. ''(But, IfSmalltalkIsSoGoodWhyDoesNobodyUseIt?)''

Hmm - RubyIsSmalltalkMinusMinus seems to be non-extant at the moment (although SmalltalkMinusMinus is, but seems to be about J*v*), and I'm no authority on SmalltalkLanguage, having only read about it, mostly on Wiki (I guess you should write at least one non-trival application in a given language before declaring yourself an authority...) However, the implication seems to be that Ruby is inferior to Smalltalk? I wouldn't want to get into a LanguagePissingMatch, so perhaps you could give me some examples of the things Smalltalk can do that Ruby can't? (Or, talking TuringComplete''''''ness as a given, things that are easier or more succinct when expressed in Smalltalk over Ruby).

One of the things I like about Ruby is that it seems to be a distillation of the good bits of lots of languages. Compared to C or Lisp, or even Perl, it's a relative newcomer to the scene. It's got a deceptively simple syntax (combined with a surprisingly unfussy parser), but has quite a lot of power if you start digging. I can definitely see a Lisp/Scheme influence in there, plus you have all the Perl regex goodness and I'm sure the object model is strongly influenced by Smalltalk. Bearing in mind 90%+ of my professional output is in C++ (with most of the remaining in Perl), I find Ruby to be a remarkably fun way of programming in my spare time.

''One of the reasons I refuse to learn Ruby is that there's absolutely nothing new in it, nothing in it that wasn't in Smalltalk many years, often decades, before it was in Ruby. I said so and someone disagreed, and then someone else pointed out how the person who disagreed is completely flat wrong at the end of my homepage, where you can still read it. So not only is there nothing in Ruby that isn't in Smalltalk but there are things in Smalltalk that aren't in Ruby, Smalltalk's syntax is elegant, powerful and doesn't make me gnash teeth, AND Smalltalk was complete and accepted long before Ruby was a gleam in anyone's eye.''

''The fact that Smalltalk is still superior to these other newish languages after so many decades isn't anything to be proud of. It's a crying shame, but it's a fact too.''

You refuse to learn Ruby, yet having not learnt it, you know there's nothing new in it, eh? ;) 
I'm not entirely convinced though, I think you can do most programming tasks in most languages, the main constraints being the environment you're working in. I guess I should download a Smalltalk compiler or interpreter and have a play with it (perhaps someone can suggest a nice cross-platform implementation). 
Out of interest, how good are Smalltalk's regex capabilities? Howsabout CallWithCurrentContinuation? 

I'll give some background: I've been writing an audio streaming/processing plugin architecture in C/C++, which is coming along nicely, I have a number of 'unit' tests written in C which construct and connect plugins by hand, but I knew that sooner or later, I'd have to knock up a UI-type application to get the most out of it. I was dreading having to do that in C+, but I happened upon AlternateHardAndSoftLayers, and decided that I needed to write my application-level code in a 'scripting' lanaguage. My main criteria were:
* language must be easy to interface to C
* language's implementation must be compilable/embeddable in a C application
* language should be targeted by SWIG

So, I started looking around, I looked at LuaLanguage, PerlLanguage, ObjectiveCaml, various SchemeLanguage''''''s, and RubyLanguage. Ruby fit my criteria best, so I started playing with it, and decided that it did the kind of stuff I was looking for my particular niche. 

I didn't actually look at Smalltalk (one of the main reasons being that it's not supported by SWIG), but that's not to say that there's anything wrong with it. But one of the things ''I'' like about Ruby is that it's written in C, so I was able to plonk the interpreter straight into my application, and tweak at it, wrap my object model, and get stuff done. If I'd have had any joy at getting the Perl5 interpreter to configure, let alone compile, I'd probably be using Perl right now, but that's another story. I guess the moral to this little story is that Ruby may well be inferior Smalltalk in however many as yet to be detailed ways, but you can still get stuff done with it. Who knows, the world changes, perhaps once we get a nice SWIG implementation for Smalltalk, I'll start using that. 

''I know things about Ruby without ever having read a single line of it in the same way that I know there's this country called China without ever having left the Western hemisphere. I also know that no meteorite made of solid gold has ever been found in China. Because it would've made the news, and it didn't.''

''Smalltalk does not have C/CC but it does have some of the best IDEs of any language.''

''As for constraints to programming, almost every programming language is Turing complete and so is theoretically unconstrained. But human beings are limited by human psychology and so there are lots of practical constraints to consider.''

''For one thing, the syntax of the C family alone is a ''severe'' constraint to programming. You don't see that constraint because you're used to it, but it doesn't mean that it isn't there, constantly making your job harder, like the Qwerty keymap.''

''The other big constraint is the conceptualization. There's a difference between functional conceptualization and OO conceptualization. And there's a world of difference between good conceptualization (Smalltalk and Lisps) and atrocious non-conceptualization (C++, Java). But again, programmers don't have ConceptOrientedMind''''''s and so they simply don't see that difference. And hell, maybe for ''them'' the difference doesn't exist.''

''I actually don't care to advocate Smalltalk. At this point, if OCaml had a decent 3D engine written in it, I'd force myself to assimilate FP. But I do want to point out that the possibility of embedding Ruby within a C application is another thing which a Smalltalker might well consider a disadvantage. Smalltalk forces you to Extend, and that's a good thing. -- RK''

So there aren't any embeddable Smalltalk interpreters? Hmm. I find myself wondering whether EmbedVsExtend could be explained in terms of statically-linked versus dynamically-linked libraries? As in you ''embed'' a lib into an application, but you can ''extend'' the application with a dll? By Extend, are we saying that having an exensible protocol or interface in an application is a good idea. I guess it would be useful to understand precisely why embedding is bad. And indeed what precisely the opposition is.

Maybe I'm being loose with the term embed: My application is presently dynamically-linked against the ruby 1.8 runtime, I've wrapped all the Ruby-specific API calls inside a Ruby''''''Interpreter class (derived from an Interpreter class). I haven't touched the Ruby source, nor do I want to, although it's a useful reference. At boot, my application creates an instance of the Interpreter class (which happens to be a Ruby interpreter), binds some function pointers to it, and gets it to load a script. That script creates a load of Ruby classes, builds the UI, and eventually returns to the application, which runs the ui loop on one thread, and manages the console on another. So once the app is up and running, I can type ruby code into the console, and try stuff out with the app running. This probably ''is'' old hat, and lisp guys have been doing it since the 50's but it ''is'' cool, and bearing in mind the fundamental insanity of most C/C++ debugging (which is essentially an autopsy), I'm feeling that by moving away from the hardware, I made the right decision.

Having dug around a bit, would I be right in saying that Smalltalk sytax, is similar to Lisp syntax, in that most of the control structures and other gubbins are kind of derived for a very small set of core concepts, as opposed to being explicitly stuck in by a language designer?

I'm having a hard time even framing these kinds of questions. Having programmed almost eclusively in C/C++ for nigh on ten years (plus being self-taught), one thing I did find, when I started looking into, say scheme, or ML, was that I had a ''massive'' culture shock. I was missing whole concepts which even introductary material seemed to take for granted. (Say stuff like closures, continuations, blocks...) I remember having a really hard time with symbols in scheme at first. I guess I was missing the 'ladder' down to the hardware. One thing that helped me was TinyScheme, which is a pretty basic Scheme implementation written in C, which I played with a lot, running lots of little scheme programs, and hacking around with the C code.

''It's really late, I'm really tired. So it took me a long time to make sense of your example, and I'm just hoping that I got it right. Near as I can figure, it has nothing to do with libs vs DLLs as you stated it, but I keep thinking that it does in a roundabout way.''

''In your example of application vs language, embedding would be sucking in all of C/C++/STL then writting your own application code. And extending would be extending (modifying) the language (possibly) by writing a framework that calls your application code, which is the case for a lot of UI code. Or alternatively, modifying STL, or modifying the language itself. But these are things you simply don't do in the C/C++ world because it's nigh impossible.''

''So embed vs extend is libraries vs frameworks. It's also application-specific code vs generic libraries. It's also extending an application using a plugin versus embedding the application into your own application. It's also writing a program versus extending the image (development environment) until it becomes your application. I mention the last because that's how you program in Smalltalk.''

''(There's actually a really good article explaining the image as a murky pond with objects swimming in its depths, What Programming In Smalltalk Is Really All About: http://www.approximity.com/cgi-bin/blogtariAgile/index.rb/Smalltalk)''

''Also, I think there may be one or two Smalltalks that can be embedded in a C application. They are marginal. None of the big Smalltalks (VisualWorks, DolphinSmalltalk, VisualAge, Squeak) can be called from an external language though I know at least the first three can call other languages.''

''For the precise reasons why embed is bad and extend is good, follow the external link on EmbedVsExtend with the python example. Or try to figure out why embed is bad in each of the examples above. Like, is it better to write a plugin for a standard browser, or to write a new browser that includes the old one? Things like that.''

''You are entirely correct about Smalltalk syntax. Smalltalk was derived partly from Lisp though it isn't functional enough to qualify as Lisp. The big difference between Smalltalk syntax and Lisp syntax is that Smalltalk,''

* has a more ''obviously'' special syntax for lambda [:x y | x squared + y] instead of (lambda (x y) (+(square x) y))
* has no syntax for evaluation, unlike Lisp where () parentheses means 'evaluate', so
** ([object message]) does not evaluate the lambda (block in ST lingo), although ([object message] evaluate) does
* has no nice syntax for AbstractSyntaxTrees and is very gratuitously ''not'' homoiconic

''If you had chosen to extend Ruby, you would have made your application into a DLL which Ruby would load from within a Ruby program. The executable you would ship would be a Ruby executable with accompanying C DLLs.''

''Jon, I really do appreciate that you're trying to understand these issues. I haven't always appreciated this but I certainly do now. Thank you.''

-- RK

Aha. ''Now'' I understand why the chapter in the Ruby manual detailing the C interface is called ''Extending'' Ruby! To be honest though, I think I'm actually extending ''and'' embedding Ruby. My executable is about 250 lines of C++, which bootstraps a ruby interpreter and a console, the rest of the app ''is'' accompanying C DLLs. Plus, I have a few unit tests written in pure ruby which basically load DLLs and exercise their objects. The Ruby boot script does pretty much run standalone (except for a couple of oddities which I ought to be able to track down). The only thing is that I have to manually start the UI loop (as it's not started by the script), then the console is tied up executing the ui loop, but I'm sure this isn't insurmountable.

One thing I didn't mention, is that my app's object model is written in C (primarily because C++ dynamic linkage sucks). But, I decided on a very consistent naming convention, so that during the make, I have a little Ruby script which parses my C header files and autogenerates C++ and Ruby bindings. The C++ bindings are little more than syntactic sugar, but the SWIG output for the Ruby bindings gets compiled into each DLL, so they can be loaded into a ruby interactive shell via require, so basically I am extending?

I guess where I went wrong was in trying to package the app in a nice 'exe' file, which is how all C apps are traditionally packaged... There's some part of me which feels uneasy about end users seeing sourcecode, maybe this is just a C thing?

''To confirm your suspicion, yes you are extending. Does the C++ code do anything beyond starting Ruby and packaging everything nicely?''

''In the case of Smalltalk, it's usual to strip an image you ship of any development tools; browsers, debuggers, the whole lot. So in that sense, nice packaging isn't just a C thing. I'm not quite sure what the point of it is beyond just not trusting users or third-party programmers.''

''It makes sense to ensure that the image starts your code right off the bat. It even makes sense to hide development tools so that users don't get confused. Excluding exceptional situations, it doesn't make sense to eliminate them from the image.''

''Just how much source code would users be exposed to without the clean up? Is it analogous to the Linux bootup process giving you scads of marginally useful information vs Windows giving you a blank splash screen?''

The C++ boot code literally just kicks off the Ruby interpreter, feeds it a script, and falls into the UI main loop once the interpreter finishes with the script. My 'grand vision' was that the C++ booter and the DLL's could basically serve as an application 'substrate', and you could supply different scripts for different applications (or different flavours of application). I was thinking about providing all the Ruby source in a zip archive or similar, and have the booter unzip everything at init, so the source code is hidden from casual viewers.

I guess keeping your source hidden is partly a trust thing, but I guess it does remove one unknown from the system - if someone's reporting some hard to reproduce problem, at least your source is in the condition you left it in and hasn't been tampered with...

----
  Jon doesNotUnderstand: Smalltalk
I've been sufficiently inspired to download SqueakSmalltalk and have a play with it. My initial results aren't particularly astounding. I tried to get some text to appear in the Transcript and failed utterly. Although I did manage to paint a picture... This is nothing like any programming (or windowing) environment I've encountered. Still, there does seem to be something approximating a tutorial. Let's see how we get on...

''I'd recommend against Squeak because of the chance that its bizarre and broken UI will turn you off Smalltalk. Dealing with ST is a tall enough task that you don't need to deal with a different UI at the same time, or to associate the two together. Frankly, I'd recommend SmalltalkExpress but that's no longer an option. I think Dolphin might be your best starting point (http://www.bitwisemag.com/copy/other/download/download_dolphin_smalltalk.html).''

I did download the Dolphin installation, although unfortuanately, my Windows fell over shortly afterwards, so I'm temporarily running Debian until I can attempt a Windows reinstall (I'm 5000 miles from my CD_ROM drive - long story), however I'll give it a go in a couple of weeks. Perhaps someone can recommend a decent Smalltalk dist for Linux?

''VisualWorks Non-Commercial.''

''And I retract my condemnation of Squeak. Apparently, I was just ''personally'' afflicted with some really weird bugs.''

''Jon, I liked SmalltalkHelloWorld, it's a very good observation. But if you just want help or support then you might want to consider irc.parcplace.net and/or FreeNode's #squeak channel. I'd give you my email address but I've seen nowhere private to send it.''

Thanks - glad you enjoyed it. It certainly helped me to get some understanding as to why surface comparisons between Smalltalk and <insert language of choice> inevitably seem to get off on the wrong foot. It seems to me that Smalltalk is more than just a language, it's a whole way of doing things, and that way of doing things doesn't map easily onto what I'd refer to as 'common practice' (with the qualifier that it's only common practice from my POV). At the moment I kind of feel that that cuts both ways: if I want to get really into Smalltalk I'm going to have to learn a new IDE, (and I've invested a lot of time into vim so that VimIsMyIde, precisely to avoid having to do that. Vim also has the benefit that I can wander into any office in the world download it and start working, without getting tied up in purchase requests and so on, but this is an aside...)
Also, this image-based business is new to me, every language I've encountered so far ultimately uses text files as the unit of currency. So, I'm not sure how much of my present experience will be of use to me in Smalltalk. Oddly, my knowledge of Ruby seems to be what's giving me the most mileage at the moment. I think if I hadn't encountered Ruby, I'd be ''utterly'' lost in Smalltalk (then again, it's clear that Ruby borrows Smalltalk concepts). For example, I know in Ruby pretty much everything will respond to 'methods', so it didn't take long for me to discover that 'inspect' has broadly analogous behaviour in Smalltalk. If I'd only had experience in say, C++, I don't think that would have occurred to me without trawling through docs and tutorials.


----
http://www.c2.com/cgi/RecentChanges?days=3

Site title search: [Search]
----
CategoryHomePage