Because not enough of the people here have their Lips on my weenie.

blakeyrat

Yes, they are text based. No, that is not a bad thing.

Then you and I will never agree on anything, ever.

I can't even imagine how shitty a non-graphical debugger would be. Like, simple fucking stuff like being able to see watch variables and the stacktrace simultaneously would be nightmarish. And God forbid you just click the line of code you want to be a breakpoint, merely setting a breakpoint would require knowing arcane wizardry. Ugh.

@Mikael_Svahnberg said:

I find it interesting that many "modern" trends in progamming and progamming languages are builtin into lisp. For example, callback programming that is all the rage in node.js?

That "modern trend" that was state-of-the-art in your 1991 Macintosh. Right.

Insert obligatory rant about nobody in IT having any knowledge whatsoever of the history of their own damned field.

dkf

@blakeyrat said:

being able to see watch variables and the stacktrace simultaneously

Needing to see the stack trace to debug the code:

Mikael_Svahnberg

Good morning. I hope you are feeling better today.

@blakeyrat said:

Then you and I will never agree on anything, ever.

I can't even imagine how shitty a non-graphical debugger would be. Like, simple fucking stuff like being able to see watch variables and the stacktrace simultaneously would be nightmarish. And God forbid you just click the line of code you want to be a breakpoint, merely setting a breakpoint would require knowing arcane wizardry. Ugh.

Text-based != CLI. Of course you can split your window into several frames (or vice versa if you use the arkane Emacs terminology) displaying stack traces etc. Of course you can use your mouse to click on a line and set breakpoints. What you don't get is an animation of a cow running across the screen and telling you that the breakpoint is set (actually, with the now builtin SVG support you could probably do that).

@blakeyrat said:

That "modern trend" that was state-of-the-art in your 1991 Macintosh

I am not sure I follow you here. Would you mind elaborating?

@blakeyrat said:

Insert obligatory rant about nobody in IT having any knowledge whatsoever of the history of their own damned field

No, I will not, because that is true for all subject areas, even outside IT. But you will forgive me if I sometimes indulge in a nostalgic "we had that in my day too. Glad to see that they've finally found a use for the concept, but I don't get what the hype is all about."

blakeyrat

@Mikael_Svahnberg said:

Text-based != CLI. Of course you can split your window into several frames (or vice versa if you use the arkane Emacs terminology) displaying stack traces etc.

Wow, if only there were some amazing technology invented to allow an application to display information in more than one window... imagine how convenient that would be.

@Mikael_Svahnberg said:

What you don't get is an animation of a cow running across the screen and telling you that the breakpoint is set (actually, with the now builtin SVG support you could probably do that).

See the funny thing is you're making fun of Visual Studio by exaggerating how clown-like a GUI is. "Hahaha look at those GUI losers, I bet they have animated happy cows running around the screen!"

But the only product I've ever used that made silly cow jokes was the open source APT, which had "Super Cow Powers" or whatever the fuck it says when you run it.

@Mikael_Svahnberg said:

I am not sure I follow you here. Would you mind elaborating?

AppleEvents, the "correct" way of programming applications for MacOS 9+ was all callback-based.

@Mikael_Svahnberg said:

No, I will not, because that is true for all subject areas, even outside IT.

Perhaps, but I'm not in any of those subject areas.

@Mikael_Svahnberg said:

But you will forgive me if I sometimes indulge in a nostalgic "we had that in my day too. Glad to see that they've finally found a use for the concept, but I don't get what the hype is all about."

Hey, you were the one trying to claim Node.JS was this brand-new revolutionary idea.

ScholRLEA

@Mikael_Svahnberg said:

Text-based != CLI. Of course you can split your window into several frames (or vice versa if you use the arkane Emacs terminology) displaying stack traces etc. Of course you can use your mouse to click on a line and set breakpoints. What you don't get is an animation of a cow running across the screen and telling you that the breakpoint is set (actually, with the now builtin SVG support you could probably do that).

Note that this text-based is a limitation - and a deliberate one - on the part of one Emacs version, albeit the most widely used one (Gnu Emacs), and even then it is more of a default than an actual limitation. XEmacs is quite happy having several windows and other visual enhancements, as are some other implementations. Gnu Emacs has anumber of extensions which will improve the UX, but those already familiar with Emacs rarely seem to use them and those who aren't don't know about them, so... yeah.

So why does Stallman keep insisting that Gnu Emacs continue to be text-based? Because it is designed to work on any system that supports ncurses. I'll give this one to Blakey, as it is a pretty bizarre form of backwards compatibility to be enforcing in 2015, but given that there are a lot of headless servers out there on which one might want to use Emacs if you don't like vi and find nano too restrictive, it is one that isn't as unreasonable as it sounds. I use Gnu Emacs myself, so at least some people find it acceptable.

ScholRLEA

@blakeyrat said:

Hey, you were the one trying to claim Node.JS was this brand-new revolutionary idea.

Funny, I was pretty sure that his point was that it was the Node.JS partisans who were saying that, and that they were wrong. Thank you for backing up his point.

That doesn't change the fact that callbacks (or rather, hooks) have been a common idiom in Lisp since the 1960s.

blakeyrat

@ScholRLEA said:

That doesn't change the fact that callbacks (or rather, hooks) have been a common idiom in Lisp since the 1960s.

Well woop-de-shit.

And yet I bet MacOS 9 had more actual productive applications developed for it in one year than LISP did in that 20+ years. I bet I've used 2 orders of magnitude more applications developed in PASCAL than in LISP. And PASCAL is widely-considered a dead language.

My general point here is: is LISP were so goddamned good and useful, why the fuck is it so obscure? Like, shouldn't 40% of my desktop applications be in LISP? Wouldn't Microsoft and Oracle add LISP to the CLI/JVM?

The answer is: it's not useful. It's just hypnotic to a certain type of person and thus won't fucking go away.

cartman82

@blakeyrat said:

I just want someone to promote LISP but telling me how it solves an actual problem in reality. Instead of all the abstract abstractness.

Practical problem solved by LISP: how to make a living publishing computer science papers about abstraction

Bort

@blakeyrat said:

My general point here is: is LISP were so goddamned good and useful, why the fuck is it so obscure?

The fallacy here is the idea that people always use the best tools. You've said that C/C++ are shitty languages - why are they used so much?

@blakeyrat said:

Wouldn't Microsoft and Oracle add LISP to the CLI/JVM?

Someone else did.

These things are demand driven. Companies develop what people will buy. People will buy what they know works/what they're familiar with. And Lisp/CL/Scheme/Clojure has too many parenthesizes so damn it's powerful feature set that I apparently don't realize MyFavoriteLanguage has been cribbing for years.

@cartman82 said:

Practical problem solved by LISP: how to make a living publishing computer science papers about abstraction

The complaints about lack of practical problem solving seem kind of hollow - the fact that it hasn't been used widely is reason not to use it? Even when the #1 reason for rejection is "too many parens"?

If we're talking about the original 1950's LISP - it wasn't supposed to solve any practical problems. It was a research language that existed to explore programming language ideas with the idea that other languages would learn from it and pick up those ideas. In that capacity, it was a smashing success.

Scheme - also used an academic language; used for teaching; influenced the good parts of Javascript.

Common Lisp - Microsoft Bob? I never liked CL, either. Too big and noisy.

Clojure - actual, successful commercial language with a user base that's still growing. Don't knock it until you've tried it.

Magus

@blakeyrat said:

add LISP to the CLI/JVM?

People have. Clojure being the easiest example. It isn't the best Lisp, but it is one.

And besides, are you really saying that no one uses AutoCAD?

antiquarian

@blakeyrat said:

My general point here is: is LISP were so goddamned good and useful, why the fuck is it so obscure? Like, shouldn't 40% of my desktop applications be in LISP? Wouldn't Microsoft and Oracle add LISP to the CLI/JVM?

The answer is: it's not useful.

You seem to have more blakeyfacts than usual today. Maybe it's time for a vacation?

Franz Inc: Allegro Common Lisp and Common Lisp Products

Franz sells a Common Lisp implementation. Their pricing starts at $599 per copy. Maybe you'd like to email Franz and tell them all of their customers are idiots for paying for something that isn't useful?

Magus

Hey look, Even Boeing uses them!

I particularly like this one:

Izware
Application: Mirai
Izware maintains the Mirai application originally created by Nichimen Graphics. Mirai is still used extensively throughout the Animation Community, and was used in the Lord of the Rings Film Trilogy. Former Nichimen Graphics employee, Bai Raitt, used Mirai to design and build the system animators used to create the faces of some of the Trilogy's more unique characters -- Gollum, Balrog, Cave Troll and Treebeard.

...Oh no... Square used it on the Final Fantasy movie...

Mikael_Svahnberg

@blakeyrat said:

Wow, if only there were some amazing technology invented to allow an application to display information in more than one window... imagine how convenient that would be.

, but I am not going to educate you on what you can or cannot do in emacs.

As for the imagined jibe at visual studio (discoquote is broken at the moment). I don't make fun of applications I have not used, which includes visual studio. i was trying to come up with a creative use of graphics for a debugger because I could not see an actual need for it.

blakeyrat

@Bort said:

The fallacy here is the idea that people always use the best tools. You've said that C/C++ are shitty languages - why are they used so much?

Because there was a time when there were no better choices.

But here's the thing? LISP is from the 1960s. So it has ALWAYS been available as "the better choice".

So why was Mac Classic written in PASCAL and not LISP? Why was Microsoft Office written in C++ and not LISP? LISP was available to the people founding these projects.

Bort

@blakeyrat said:

Because there was a time when there were no better choices.

Let me re-phrase my question: Why are they still used so much?

And I guess they're not. People are using other languages now. Languages that learned from LISP. Finally.

You like lambdas, right? Were those totally impractical until Microsoft added them to C#? Why couldn't they be added earlier? What took so long? If they're such a good idea, why weren't they in earlier, widely-used languages?

So this thread started about LISP macros. How long is it going to take for Java, C#, et al to pick those up? How long will it take to understand how useful those are?

Of course, nowadays, we have a language suitable for commercial development with a strong community that is itself a lisp - Clojure. So just use that.

@blakeyrat said:

But here's the thing? LISP is from the 1960s. So it has ALWAYS been available as "the better choice". So why was Mac Classic written in PASCAL and not LISP? Why was Microsoft Office written in C++ and not LISP?

Because the 1960's LISP was an academic research language that wasn't suitable for commercial development? Duh?

You should have asked - Why didn't people use CL? Why aren't they using Clojure? And I'd say - they did and they are. More and more.

blakeyrat

@Bort said:

You like lambdas, right?

Not particularly.

I like LINQ, which lambdas enable. But nobody in LISP-land came up with LINQ, Microsoft did.

@Bort said:

So this thread started about LISP macros. How long is it going to take for Java, C#, et al to pick those up?

You'd have to first convince me they should. C/C++ macros are a wide-awake nightmare for maintainable code.

@Bort said:

Clojure. So just use that.

What if I want to make a desktop app?

antiquarian

@Bort said:

You should have asked - Why didn't people use CL?

I think it's a safe bet he doesn't know what CL is.

EDIT: On second thought, it's a safer bet that he doesn't care what CL is, given that he is still spelling LISP with all caps even after I pointed out to him that that hasn't been correct in more than 30 years.

Bort

@blakeyrat said:

But nobody in LISP-land came up with LINQ, Microsoft did.

C/C++ macros are a wide-awake nightmare for maintainable code.

I wasn't going to just brush you off as not knowing what you're talking about. Then you changed my mind.

This reminds me of a comic from a few weeks ago:

The design of LINQ was greatly influenced by Haskell more directly than any lisp, but I do remember laughing out loud when watching A & S's SICP class on MIT OCW where he at one point describes a chain of lazily-evaluated transformers on a sequence (map, filter, fold - compare to - Select, Where, Aggregate). That course was taught in Scheme. Homo-iconic syntax, the inspiration for Expression Trees is a lisp original.

So everything in LINQ has been around a long, long time. MS just packaged it up and gave it marketable now. How very Apple of them.

I like LINQ. I'm glad it's there. And I think it's important to recognize where it came from so we can learn more.

And if you were using a language with lisp macros, many of your favorite language's features could have been implemented as a library instead of waiting for 10 years for the compiler team to get around to it. In Clojure, core.typed (the type system) and core.async (like c#'s async/await) are libraries. Because you can do that in Clojure.

Extra stuff:

But what practical problem does LINQ solve?

Insert obligatory rant about nobody in IT having any knowledge whatsoever of the history of their own damned field.

make reference to the Blub Paradox

I've had this conversation too many times. Too many times even with the same person.

Magus

@Bort said:

And if you were using a language with lisp macros

Nemerle is quite good.

blakeyrat

@Bort said:

And if you were using a language with lisp macros, many of your favorite language's features could have been implemented as a library instead of waiting for 10 years for the compiler team to get around to it.

But if it had, then nobody would be able to move from one C# project to another without relearning EVERYTHING.

@Bort said:

But what practical problem does LINQ solve?

It makes set-based operations in otherwise-procedural code actually look and behave like set-based operations.

antiquarian

@blakeyrat said:

But if it had, then nobody would be able to move from one C# project to another without relearning EVERYTHING.

Properly written Lisp macros don't have that problem. Take with-open-file as an example:

CLHS: macro WITH-OPEN-FILE

(with-open-file (foo "no-such-file" :if-does-not-exist nil)
   (read foo))

I don't expect you to be able to read this, but others will, and probably wouldn't even realize they were using a macro.

I've said it here before: if you're not writing a library, you probably shouldn't use Lisp macros. If you are writing a library, you should write macros if it makes life easier for the people who will use your library (cf. with-open-file above).

dkf

@antiquarian said:

Take with-open-file as an example

The interesting thing is there are other languages that can do that sort of thing, but they don't call what they're doing “macros”. The Smug Lisp Weenies treat this as proof that what they're doing is superior. Everyone else rolls their eyes and doesn't try to correct them; SLWs don't listen to the outside world.

antiquarian

@dkf said:

The interesting thing is there are other languages that can do that sort of thing

Example, please.

Choonster

@antiquarian said:

@dkf said:
The interesting thing is there are other languages that can do that sort of thing

Example, please.

I don't fully understand the documentation of that macro (I don't know Lisp), but it looks quite similar to C#'s using statement or Java's try-with-resources statement.

Both of these are syntax sugar for try .. finally that allow any object that implements the appropriate interface to be disposed/closed when control leaves the block.

antiquarian

@Choonster said:

Both of these are syntax sugar for try .. finally that allow any object that implements the appropriate interface to be disposed/closed when control leaves the block.

E_FOREST_NOT_FOUND_TOO_MANY_TREES

The point isn't that Common Lisp has something similar to the try finally construct (or using to be more accurate). The point is that you could add it yourself even if the language designers didn't.

Choonster

@antiquarian said:

@Choonster said:
Both of these are syntax sugar for try .. finally that allow any object that implements the appropriate interface to be disposed/closed when control leaves the block.

E_FOREST_NOT_FOUND_TOO_MANY_TREES

The point isn't that Common Lisp has something similar to the try finally construct (or using to be more accurate). The point is that you could add it yourself even if the language designers didn't.

Ah, I had a feeling I was missing something.

I can't really think of any way using could be implemented as a method in C# unless you had a method that took two delegates (one for the declarations and one for the body) and you managed to extract all values from the declaration and pass them as arguments to the body (which I'm not entirely sure is possible).

blakeyrat

@antiquarian said:

The point is that you could add it yourself even if the language designers didn't.

Because you can't in C#, peoples!!! There's no such thing as "extension methods"! They are CRAZY FANTASY!

antiquarian

OK, how would you implement using in C# with extension methods, assuming it didn't already exist?

blakeyrat

I would piss on a dog. And it would run away yelping. And then I'd laugh.

antiquarian

No further questions.

turns toward bench

Your honor, the defense rests.

rc4

@antiquarian said:

Your honor, the defense rests.

Did they have to install Flash player?

antiquarian

I don't get it.

rc4

Holy fuck, it's today's article... http://thedailywtf.com/articles/installing-flash-player-is-hard-work

blakeyrat

Nobody reads the front page.

Magus

Choonster actually explained how, though you wouldn't be able to use arbitrary syntax. That may not be an issue.

public static void Using(this Action<IDisposeable> action, IDisposeable instance)
{
  try
  {
    action(instance);
  }
  finally
  {
    instance.Dispose();
  }
}

Could be used something like:

Action<IDisposeable> b = thing => {
  blah;
  blahblor.Gorgbakh();
}

b.Using(new DisposeableThing());

I can definitely see the advantage of macros if you want to specify the syntax, but in some ways, I don't mind that C# makes you be slightly more formal about this stuff.

antiquarian

@Magus said:

I can definitely see the advantage of macros if you want to specify the syntax, but in some ways, I don't mind that C# makes you be slightly more formal about this stuff.

Would it be worthwhile to find another example (or preferably let @ScholRLEA do it)?

Choonster

I actually just wrote something similar, but slightly more convoluted here.

My version uses a Func as the equivalent of the using block's initial declaration statement and an Action as the equivalent of the body. The using block allows you declare any number of variables to be disposed, but methods can obviously only return a single value; so I had to use a collection of IDisposable as a substitute.

Edit: I've updated the code with @Magus' suggestion.

Magus

I'd just make the Action take an array, then make the method take params IDisposeable. No real need for a Func, imo.

dse

@antiquarian said:

ITA Software would like to have a word with you.

Same ITA as the one in Anathem?

Magus

That one is us.

Kian

@Bort said:

How long will it take to understand how useful those are?

Isn't the big selling point of macros that you can change the syntax of the language, not just do text substitution? So the great benefit it gives you is that you can laboriously build a more expressive language on top of your more limited one? If you just use a language with those features baked in, you save yourself the trouble of building it.

A hammer is not a house, even if you can use a hammer to build a house. And while it may be more "useful" than a house, because it can be used to build a house or a boat while a house is just a house, if all I want is a house the ability to also make a boat is useless. Also, if I want a house but don't know how to build one, all a hammer gives me is a shitty house.

Lisp macros are a hammer. They're not useful in and of themselves, they just make the thing you actually want to do easier. The problem is that to use them you need to know both the thing you actually want to do, and how to use macros to build a language to describe how to do the thing you want to do. Or you can use a language already intended to do that thing.

@antiquarian said:

I don't expect you to be able to read this, but others will, and probably wouldn't even realize they were using a macro.

How do they know the order of the parameters in "with-open-file"? What if two libraries implement a macro with the same name and function, but they use different order of parameters? When you change from one library to the other, you have to relearn how to use these features. If you use a language which already has that, you learn it once and carry that knowledge from project to project.

antiquarian

@Kian said:

How do they know the order of the parameters in "with-open-file"? What if two libraries implement a macro with the same name and function, but they use different order of parameters? When you change from one library to the other, you have to relearn how to use these features. If you use a language which already has that, you learn it once and carry that knowledge from project to project.

In the case of with-open-file, the order of parameters is listed in the link (which you obviously didn't read) and they only have to learn it once as it's a part of the ANSI standard.

In the case of libraries people write, you do know that Common Lisp has documentation strings and the ability to define keyword parameters, right? And you wouldn't expect to use a C# library without reading about the different classes and methods, right?

All told, this strikes me as a "sour grapes" type of objection.

Bort

@Kian said:

Isn't the big selling point of macros that you can change the syntax of the language, not just do text substitution?

They're more like functions that re-arrange syntax. Pervasive use would be ill-advised, just like any language capability. Anything can be mis-used. You could claim that some things are more likely to be mis-used, but where did you get that idea? From your extensive experience? Some here don't even seem to understand what the feature in question does.

@Kian said:

So the great benefit it gives you is that you can laboriously build a more expressive language on top of your more limited one?

The benefit isn't to end-developers so much as library developers.

@Kian said:

Or you can use a language already intended to do that thing.

And if your language has powerful features like lisp macros, it's much more likely to gain that feature as a library.

@Kian said:

How do they know the order of the parameters in "with-open-file"?

How do they know about the order of the paramters in any function?

@Kian said:

What if two libraries implement a macro with the same name and function, but they use different order of parameters?

Same with functions? (namespaces)

All I'm trying to convince people is that something is worth a try. And then they talk to me like they know better despite not having any experience with it and sometimes demonstrating a clear misunderstanding of the concept.

Bort

@antiquarian said:

OK, how would you implement using in C# with extension methods, assuming it didn't already exist?

meh, i guess you could implement that with a method that took a lambda or something...

wild-ass guess:

static B Using<A, B>(Func<A> decl, Func<A, B> body) where A : IDisposable
{
    var a = decl();
    try
    {
        return body(a);
    }
    finally
    {
        a.Dispose();
    }
}

Bort

@blakeyrat said:

It makes set-based operations in otherwise-procedural code actually look and behave like set-based operations.

If you could find some way to monetize your ability to miss the point, you'd be a rich man.

antiquarian

@Bort said:

All I'm trying to convince people is that something is worth a try. And then they talk to me like they know better despite not having any experience with it and sometimes demonstrating a clear misunderstanding of the concept.

That's because of the Everyone Knows™ thing I mentioned on the Haskell/Yesod thread.

Kian

@antiquarian said:

In the case of with-open-file, the order of parameters is listed in the link (which you obviously didn't read) and they only have to learn it once as it's a part of the ANSI standard.

You didn't answer the second sentence. What if someone decides to write their own macro to do this? Or if two different libraries implement some other functionality that the standard doesn't? If your point is that no one is supposed to use macros because the standard library already provides a comprehensive set of them, then there's no benefit to the language having macros.

@antiquarian said:

you do know that Common Lisp has documentation strings and the ability to define keyword parameters, right?

How could I not?<That's sarcasm />

The point is, however, that if macros basically provide you with facilities other languages incorporate directly, then you need to learn the macro for each of those facilities, for each library you ever use. If the language incorporates it, then you learn it once.

Having an extensible language is only as good as the extensions you can create. Lisp aficionados see only the potential macros enable, but ignore the cost.

@antiquarian said:

All told, this strikes me as a "sour grapes" type of objection.

No, it's a simple cost-benefit analysis. Of course, there's Alan Perlis' quote, "LISP programmers know the value of everything and the cost of nothing." So that notion may be foreign.

I don't code just for the love of coding, I code to tackle problems that I find interesting, and extending a language is not a problem that interests me in general. I prefer to grab a language that already does what I need to do to solve my target problem.

antiquarian

@Kian said:

You didn't answer the second sentence.

@Bort already answered your questions. If you're not happy with his answers, you won't be happy with mine either. I'm still not convinced that they were genuine questions anyway. If you really want to know the benefits of Lisp macros, you can search comp.lang.lisp and you'll get good answers. If you just want to convince yourself and others that you're not missing out on anything, feel free to do so but leave me out of it.

Bort

@Kian said:

extending a language is not a problem that interests me in general.

So then you might want to use a language that better allows for development of useful libraries.

You might never use reflection if your language has it, but you still benefit from libraries and frameworks that make use of it.

Kian

@Bort said:

All I'm trying to convince people is that something is worth a try.

Well, if macros are only intended for library maintainers, then don't tout them as this great language feature to get people interested in them. My post wasn't aimed at steering people away from Lisp. I've toyed with it a bit and I don't hate it. It has some useful concepts that can inform how you code in other languages. It's just not very practical.

It doesn't help that the kind of people who champion it are usually the kind of people that champion emacs too.

@antiquarian said:

I'm still not convinced that they were genuine questions anyway.

That's a nice way of deflecting attention from the issue. Still, you both said basically "it's not intended for regular users of the language". Then don't say they're this great thing to people who don't know the language. If they're great for library maintainers, good for them, but most people aren't library maintainers.

@antiquarian said:

If you just want to convince yourself and others that you're not missing out on anything, feel free to do so but leave me out of it.

I'm not saying that macros are worthless. They have a value, and they have a cost. Just like most things. When applied to the problems I find interesting, the value doesn't amount to cover the cost.

For instance, I like working on systems where resource constraints matter. Where the hit of going to memory more than you need to is actually experienced by the user, and where performance is impacted by how elements of a struct are arranged in memory.

Does Lisp and friends offer me the ability to set the layout in memory of a structure, and arrange a bunch contiguously in memory? My understanding is that it doesn't, and the basic native data structure, the linked list, is awful in the systems I work with.