Re: Which programming language is better to start

Matthieu Villeneuve wrote:
> "Jon Harrop" <usenet@xxxxxxxxxxxxxx> wrote in message
> news:42b80b7d$0$41911$ed2619ec@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> Matthieu Villeneuve wrote:
>> > Macros are the feature that allows syntactic abstraction (and makes it
>> > easy), making it possible to extend the language with new operators
>> > that are perfectly tailored for the application domain. I would really
>> > like to know how that can be called a "low-level feature".
>>
>> AFAIK, LISP macros are unsafe whereas camlp4 is not.
>
> Unsafe? Could you please expand a little on this?

I've heard that it is much easier to introduce bugs with Lisp macros as
opposed to camlp4.

>> > Dynamic typing also frees the programmer from many constraints,
>>
>> Don't try to argue that dynamic typing is high-level. It blatantly isn't.
>
> That's right, a type system isn't high- or low-level by itself. The type
> system is just a feature that can contribute to make a language lower
> or higher level. In the case of Common Lisp, including both static and
> dynamic typing clearly contributes to making the language very high
> level.

I've addressed this.

>> > especially compared to languages with required explicit declarations.
>>
>> So not OCaml then.
>
> Note the "especially". OCaml's type system makes programming much easier
> than C or Java's, but it is still not as flexible as Lisp's.

I've addressed that too.

>> I'm still not convinced that this is higher-level (as the OP claimed).
>> The changes do not appear to be in-line with OO theory, indeed they
>> appear to grate against it by puncturing abstraction and encapsultion and
>> as for the heavy use of macros...
>
> We're not talking about "OO theory" (which would need us to agree about
> a definition of OO), but about higher-level languages. Some say that
> Common Lisp is not a proper OO language because it doesn't enforce
> access controls to members of an object (probably not even knowing that
> this would mean Smalltalk is not a proper OO language... oh well),
> but I really don't care about that.

Sure. I just objected to the statement that Lisp's OO is much higher level
than OCaml's OO. I've seen no evidence of this.

> I want a powerful language, not a language that satisfies certain
> criterions.

What's the difference?

>> - how does a condition system know where the error occurred and what
>> exactly has been computed up to that point?
>
> That's the point, if you don't unwind the stack then you can inspect
> the state of the lower frames, and even modify it, before you decide
> of the action to take.

Do you need to know about stack frames to use it?

>> Although, to the best of my knowledge, the type inference and static type
>> checking of ML requires many fundamental features which cannot be
>> implemented in LISP, e.g. checking through pattern matches.
>
> Looks to me like your knowledge is out of date, Common Lisp systems
> such as CMUCL have used type inference and static type checking for
> ages.

Can you give an example of a Lisp program doing type inference and checking
over a pattern match?

>> > The compiler gives
>> > warnings every time it detects a potential type error, but the
> programmer
>> > remains free to do whatever he wants (after all, he knows the program
>> > design better than the compiler does).
>>
>> I believe there are no advantages to that freedom.
>
> For example, one can start running a partial implementation of a program,
> not having to provide dummy "stubs" in order for it to compile, and fill
> in the blanks gradually.

You can do the same thing more safely in OCaml with polymorphic variants
(but I wouldn't).

> It's also easier to change one's mind about type
> definitions while programming, without having to change the whole program
> just to validate another design change.

That is precisely why it is a bad idea and ill advised.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
.

Relevant Pages

  • Re: Two questions together
    ... How powerful are the macros? ... > "programmable language" and as far as I know this feature is provided ... It is also said that one can hammer the Lisp so that ... I really love Lisp's syntax:) But I just want ...
    (comp.lang.lisp)
  • Re: macro for shorter array syntax
    ... How is OCaml on adding readmacros, which Lisp can do easily. ... I would not ask that of a parsed language. ... We're confident that using macros is useful to us, ... debate has legitimate points on both sides. ...
    (comp.lang.lisp)
  • Re: A "killer" macro
    ... but then Ruby is dog slow anyway: ... Having notational convenience via macros plus efficiency is a big win ... From my perspective as a Ruby programmer learning Lisp, ... thought of having a more powerful language *and* orderof magnitude ...
    (comp.lang.lisp)
  • Re: A "killer" macro
    ... Or perhaps Lisp doesn't have one thing ultra- ... with a prefix language. ... the only thing that *really* sets Lisp apart is macros. ... Ruby and C# are very different. ...
    (comp.lang.lisp)
  • Re: macro for shorter array syntax
    ... reason I turned to Lisp is that many, or even most, people in the C++ ... it is also a good idea to be careful with adding new macros. ... Hence an ideal language for implementing an interpreter for Simulink models would allow one to define block types directly, like e.g. so: ... So the actual implementation of the functionality provided by define-node-type is mostly achieved through functional libraries, MOP hackery, etc., and it is indeed still possible to define new node types by hand via defclass, defmethod and various globally-defined macro helpers, but a node definition is much more concise. ...
    (comp.lang.lisp)