Prev: The correct choice for implementation (was: A simple web clientlibrary)
Next: Solved Re: Emacs speedbar doesn't show .lisp and .asd files
From: Ron Garret on 12 Mar 2010 01:02 In article <hnbvsd$5bk$1(a)news.eternal-september.org>, Tim Bradshaw <tfb(a)tfeb.org> wrote: > On 2010-03-11 18:24:32 +0000, Ron Garret said: > > > C++ is clearly > > harder to learn than, say, Scheme, and yet I'm pretty sure that more > > people know C++ than know Scheme. > > On what basis is it then harder to learn? You're kidding, right? Are you seriously questioning the claim that C++ is harder to learn than Scheme? > I think you may be confusing > "has a small definition" with "is easy to learn". No, though being small certainly doesn't hurt, all else being equal. (But of course, being small can be taken too far. Unlambda is smaller than Scheme, but it's much harder to learn to program in Unlambda than it is to program in Scheme.) > That would make, > say, general relativity, something that is very easy to learn (much > easier than being able to cook competently, say), but I don't think > that is true. That's hardly a fair comparison. You're taking one narrow topic (GR) and comparing it to an entire field of study (cooking). A better comparison would be GR versus how to make a souffle, or learning how to cook versus learning physics. The reason C++ is hard to learn is not that it's big per se. Common Lisp is big too, but it's vastly easier to learn that C++. The reason C++ is hard to learn is that it burdens the programmer with remembering endless minutiae, all of which are essential to producing working code. Google for "C++ coding standards" and compare the result to "Scheme coding standards." There's an entire industry devoted to reminding people of the myriad things they must keep in mind while coding in C++. rg
From: Alessio Stalla on 12 Mar 2010 04:51 On Mar 11, 11:08 pm, Tim X <t...(a)nospam.dev.null> wrote: > Alessio Stalla <alessiosta...(a)gmail.com> writes: > > On Mar 11, 1:17 pm, Tim X <t...(a)nospam.dev.null> wrote: > >> Alessio Stalla <alessiosta...(a)gmail.com> writes: > >> > On Mar 11, 8:32 am, Tim X <t...(a)nospam.dev.null> wrote: > > >> >> P.S. If anyone knows of a CL library that will allow me to interact with > >> >> an Oracle database AND allow me to call stored procedures, passing data > >> >> in both directions and access ref cursors, *PLEASE* let me know - I > >> >> would still prefer to use CL for these jobs over perl. > > >> > If it's a viable option for you, you could use ABCL on the JVM and use > >> > Oracle's JDBC driver. > > >> Yes, I was thinking about that as a possible option. Don't know anything > >> about ABCL and was hoping to stick with a familiar ANSI implementation > >> such as SBCL or even CLISP. Don't know anything about the > >> interface/mapping between ABCL and java libs and wsn't sure if I was > >> going that route whether I would be better off just jumping into clojure > >> as I've been thinking about finding some project to try it out. > > > The Java access API is derived from ACL's jlinker (http:// > >www.franz.com/support/documentation/current/doc/jlinker.htm). The > > notable differences are: > > > - ACL's API assumes the JVM is a different process, while ABCL runs in- > > process, so it lacks all the functions for managing the connection > > with the JVM; and > > > - ABCL's API has the option to be a bit less verbose, letting ABCL > > choose automatically the method to call from the argument types, at > > the cost of a runtime performance hit. For example: (jcall (jmethod > > "java.lang.Comparable" "compareTo" "java.lang.Object") instance obj) > > vs (jcall "compareTo" instance obj). There's also the JSS library > > maintained by Alan Ruttenberg which is even less verbose, has more > > features and is more efficient (wrt ABCL's abbreviated API). > > Interestingly, one of the things I have to fix is a severely broken Java > spring based web api, which is partly broken because of the use of > techniques like the above to derive stored procedure arguements. > > It is going to be hard for me to again accept java style verbosity. I > had hoped I'd escaped that nightmare back in 98. > > > > >> Is there much that would take getting accustomed to in ABCL that may > >> feel 'foreign' and how ANSI compliant is it? > > > It is mostly ANSI compliant; it lacks the long form of define-method- > > combination and fails 30-something tests from the GCL ANSI test suite > > (IIRC 21k+ tests). > > Compared to other, more mature implementations with a larger user > > base, it lacks a number of things that are usually taken for granted; > > for example, the MOP is incomplete, the debugger could be improved in > > many ways (e.g. it doesn't show local variable information), the > > compiler doesn't use type information very much, etc. > > Oh, and it's the only CL implementation I know of where = fixnums are > > not always EQ, due to boxing imposed by the JVM. > > None of those seem particularly problematic. As long as the close link > with Java doesn't leave too much of a bad taste in my mouth, it could > provide what I want. In my experience, you can usually hide all the Java cruft behind Lisp abstractions. Java objects are first-class entities and as such you can pass them to regular Lisp functions, etc. You can even have CLOS generic functions dispatch on Java classes respecting their inheritance hierarchy :) Alessio
From: Tim Bradshaw on 12 Mar 2010 05:58 On 2010-03-12 00:39:12 +0000, Pascal J. Bourguignon said: > "Rationalization" and "handling of double-quotes in unix shells" in the > same sentence? Indeed so. Perl makes a much more rational job of it (for instance it does not do the nightmare repeatedly-reparsing thing that shells do and which makes shell scripts which are robust against filenames with odd characters in so hard to right), while being culturally compatible with what shells do.
From: Tim Bradshaw on 12 Mar 2010 06:00 On 2010-03-12 02:14:20 +0000, John Bokma said: > How does C prevent this? Or I don't understand what a pointer into an > array is. Implementations typically do not, but it is not allowed by the standard.
From: Tim Bradshaw on 12 Mar 2010 06:02
On 2010-03-12 05:01:59 +0000, Raffael Cavallaro said: > OK, so then perl is just the unix cancer metastasized. yeah, we all hate Unix. |