5 ms·

> I would spend a lot of time trying to figure out the actual type of the thing that I a given function That's just because your were a noob. You hadn't learne

> I would spend a lot of time trying to figure out the actual type of the thing that I a given function That's just because your were a noob. You hadn't learned and internalized the standard library yet, and you hadn't learned to understand flow and structure of types and functions and variables. I too when I started with Lisp had the same struggles, but they go away with expertise. That's why you'll hear people talk about "training wheels", when you program in a statically typed language with an extensive IDE doing a lot of static analysis for you, you basically operate constantly with training wheels on. You never really learn what class does what, what methods they have, what types things are, you rely heavily on your IDE. For example, ask an experienced Java developer to write some Java in notepad? They don't know what to import, where to find anything, completely lost, productivity hits zero. And I'm not degrading Java devs or that setup. What happens in Lisp is that you have to learn your language, you can't rely on an IDE or the compiler. In theory you could also learn Java to that level, stop using an IDE and you'll be forced to really know the language as well. Here's the kicker? Once you learn the language to that level, your productivity in it skyrockets! But until you do, its a slow crawl. And it's only ounce you've got that experience that the ability to change the program as it is running through a REPL really brings about speed, you don't use it to figure basic things like types and what standard functions exists, but to tackle real business logic or explore libraries and 3rd party APIs to get a grasp on those quickly. Take this from someone who went from strongly typed Java, C++, C#, ActionScript 3 to a Lisp. I'm now way more productive in Lisp. P.S.: Also, you'll have static analysis in Lisp as well, depending on which one and your setup. In Clojure, I have static analysis, an IDE, a connected REPL, and use all three actively.

JetSetWilly 5y ago
A typical standard lib may have thousands upon thousands of functions with many less commonly used arguments and options. If you are saying "memorise the lot" is the only route to productivity on lisp then I'm out, because that's unrealistic. And let's not get into libraries outside of the standard lib, am I expected to memorise XML parsers, graphics APIs, and so on as well? If you are saying "memorise what you commonly use" then that's fine, except that any typical program usually involves a lot of "lesser used" stuff as well.
- lispm 5y ago
  You don't have to. Lisp development environments remember all what one loads into them: the definitions, their source location, their arguments, their documentation, who calls whom, the data types, ... One can ask Lisp about all that then.
  - leprechaun1066 5y ago
    > One can ask Lisp about all that then How? As in what commands/functions/macros? Say I define a function and compile with slime, how do I get the repl to print it back to me? And with a function I loaded from an external library? Is there something like macroexpand-1 for functions which will print it out?
    - lispm 5y ago
      M-. on a symbol brings you to the source code. Common Lisp also has built in the function FUNCTION-LAMBDA-EXPRESSION, which returns the source for a function -> when Lisp has recorded its definition. Try (DESCRIBE #'some-function) in SBCL to get information about the arglist, the types, the source file. In a SLIME editor buffer try c-h m . This will display the buffer commands. There are a zillion of commands to get information about the symbols, code references, etc. On my Lisp Machine: Command: Show Source Code (a defined function spec) mts::init-facts Source code for MTS::INIT-FACTS: (defun init-facts () (setf *init-facts* '((world (loc (actor joe) (val cave))) (joe (loc (actor joe) (val cave))) (world (loc (actor irving) (val oak-tree))) (irving (loc (actor irving) (val oak-tree))) (joe (loc (actor irving) (val oak-tree))) (world (loc (actor water) (val river))) (joe (loc (actor water) (val river))) (world (loc (actor honey) (val elm-tree))) (irving (loc (actor honey) (val elm-tree))) (world (loc (actor worm) (val ground))) (joe (loc (actor worm) (val ground))) (irving (loc (actor joe) (val cave))) (world (loc (actor fish) (val river))) (irving (loc (actor fish) (val river)))))) Command: Show Callers (a symbol [default MTS::INIT-FACTS]) MTS::INIT-FACTS MTS::MICRO-TALESPIN calls MTS::INIT-FACTS as a function. MTS::MICRO-TALESPIN-DEMO calls MTS::INIT-FACTS as a function. Done. Command:
deergomoo 5y ago
Come on now, this is a silly take with more than a little elitism. An IDE (for a sufficiently static language) eliminates so much unnecessary mental load that is otherwise wasted on avoiding inevitable human errors—typos, type mismatches, forgotten cases. I don’t want what is essentially trivia swimming around in my head any more than I want to find out about the inevitable errors I’ve made when I come to compile or run my program. I want to know that no such issues exist well before then, so I can focus on making sure my program actually behaves correctly.
- didibus 5y ago
  I'm sorry, I know it can come out that way, but I am a developer that uses both statically typed languages and happily use powerful IDEs with them, and I also develop in a Lisp (Clojure more specifically), almost to a perfect 50/50 split. And I don't mean to say that you're a bad developer or not smart enough if you use an IDE. Of course you should use an IDE with Java or C# or C++. Those languages are all very good, and when paired with a good IDE can be quite productive. And even with a Lisp, you should and will want to use a powerful editor or IDE with good auto-complete, linting, jump to definitions, etc. What I'm trying to say is that to be productive in a Lisp, it's a different learning curve. You just can't come and say: "well I tried it a little bit, and I couldn't figure out how to do anything and I was really slow, so I just don't get the point of a REPL and I don't get why people claim it's a hugely productive tool." I'm telling you why, it's like complaining that you type slower on a keyboard than you can write by hand for the first year of you using a keyboard. There's a learning curve. You can't just say: "well I can't figure this out. Where is the IDE to help me with it? Where are the type definitions? Where is the compiler to guide me? I guess the Lispers are just full of it." No, you didn't do what Lispers do. Lispers learn the language until those things are no longer a problem, and then they unlock a new found productivity combined with the ability to work inside a running program, quick iteration, being able to extend and mold the language to what is most efficient for you and your problem, etc. It's 100% ok if you say that you don't feel it's necessary for you to go the extra mile to learn a Lisp properly. That's fine, if you find you're sufficiently successful and productive already with your language, that's totally cool. But you can't not properly learn it, and then claim that the claims of those who have are invalid. It's like if you started to doubt a touch typist that's telling you that learning to touch type makes you a more productive typist, because when you tried it was hard to learn and you were slower at typing.
rmbyrro 5y ago
This was unnecessary, mate
deleted 5y ago
[deleted]

JetSetWilly 5y ago

A typical standard lib may have thousands upon thousands of functions with many less commonly used arguments and options. If you are saying "memorise the lot" is the only route to productivity on lisp then I'm out, because that's unrealistic. And let's not get into libraries outside of the standard lib, am I expected to memorise XML parsers, graphics APIs, and so on as well? If you are saying "memorise what you commonly use" then that's fine, except that any typical program usually involves a lot of "lesser used" stuff as well.

lispm 5y ago
You don't have to. Lisp development environments remember all what one loads into them: the definitions, their source location, their arguments, their documentation, who calls whom, the data types, ... One can ask Lisp about all that then.
- leprechaun1066 5y ago
  > One can ask Lisp about all that then How? As in what commands/functions/macros? Say I define a function and compile with slime, how do I get the repl to print it back to me? And with a function I loaded from an external library? Is there something like macroexpand-1 for functions which will print it out?
  - lispm 5y ago
    M-. on a symbol brings you to the source code. Common Lisp also has built in the function FUNCTION-LAMBDA-EXPRESSION, which returns the source for a function -> when Lisp has recorded its definition. Try (DESCRIBE #'some-function) in SBCL to get information about the arglist, the types, the source file. In a SLIME editor buffer try c-h m . This will display the buffer commands. There are a zillion of commands to get information about the symbols, code references, etc. On my Lisp Machine: Command: Show Source Code (a defined function spec) mts::init-facts Source code for MTS::INIT-FACTS: (defun init-facts () (setf *init-facts* '((world (loc (actor joe) (val cave))) (joe (loc (actor joe) (val cave))) (world (loc (actor irving) (val oak-tree))) (irving (loc (actor irving) (val oak-tree))) (joe (loc (actor irving) (val oak-tree))) (world (loc (actor water) (val river))) (joe (loc (actor water) (val river))) (world (loc (actor honey) (val elm-tree))) (irving (loc (actor honey) (val elm-tree))) (world (loc (actor worm) (val ground))) (joe (loc (actor worm) (val ground))) (irving (loc (actor joe) (val cave))) (world (loc (actor fish) (val river))) (irving (loc (actor fish) (val river)))))) Command: Show Callers (a symbol [default MTS::INIT-FACTS]) MTS::INIT-FACTS MTS::MICRO-TALESPIN calls MTS::INIT-FACTS as a function. MTS::MICRO-TALESPIN-DEMO calls MTS::INIT-FACTS as a function. Done. Command:

deergomoo 5y ago

Come on now, this is a silly take with more than a little elitism. An IDE (for a sufficiently static language) eliminates so much unnecessary mental load that is otherwise wasted on avoiding inevitable human errors—typos, type mismatches, forgotten cases. I don’t want what is essentially trivia swimming around in my head any more than I want to find out about the inevitable errors I’ve made when I come to compile or run my program. I want to know that no such issues exist well before then, so I can focus on making sure my program actually behaves correctly.

didibus 5y ago
I'm sorry, I know it can come out that way, but I am a developer that uses both statically typed languages and happily use powerful IDEs with them, and I also develop in a Lisp (Clojure more specifically), almost to a perfect 50/50 split. And I don't mean to say that you're a bad developer or not smart enough if you use an IDE. Of course you should use an IDE with Java or C# or C++. Those languages are all very good, and when paired with a good IDE can be quite productive. And even with a Lisp, you should and will want to use a powerful editor or IDE with good auto-complete, linting, jump to definitions, etc. What I'm trying to say is that to be productive in a Lisp, it's a different learning curve. You just can't come and say: "well I tried it a little bit, and I couldn't figure out how to do anything and I was really slow, so I just don't get the point of a REPL and I don't get why people claim it's a hugely productive tool." I'm telling you why, it's like complaining that you type slower on a keyboard than you can write by hand for the first year of you using a keyboard. There's a learning curve. You can't just say: "well I can't figure this out. Where is the IDE to help me with it? Where are the type definitions? Where is the compiler to guide me? I guess the Lispers are just full of it." No, you didn't do what Lispers do. Lispers learn the language until those things are no longer a problem, and then they unlock a new found productivity combined with the ability to work inside a running program, quick iteration, being able to extend and mold the language to what is most efficient for you and your problem, etc. It's 100% ok if you say that you don't feel it's necessary for you to go the extra mile to learn a Lisp properly. That's fine, if you find you're sufficiently successful and productive already with your language, that's totally cool. But you can't not properly learn it, and then claim that the claims of those who have are invalid. It's like if you started to doubt a touch typist that's telling you that learning to touch type makes you a more productive typist, because when you tried it was hard to learn and you were slower at typing.

rmbyrro 5y ago

This was unnecessary, mate

deleted 5y ago

[deleted]