Comedy!!!

I'm always chuckling at those types of questions: "What is the language good for?" Ha! Somebody wrote a roller coaster simulator in Excel. So, anything is what can be written in the language...

Perfectly relaxing tone, perfect podcast for dog walking and before going to bed. Very good takes btw. I fully agree!

Great book, really enjoying it.

I have a information system project development class and got this assignment, tysm for the explanation.

Its not a problem, it is what it is. You dont complain to a wizard about how they write their spellbook. Imagine a world that every wizard now has to write their spell in a particular way

@Eric. Your videos cover a lot of the questions I have about functional programming. Thanks so much for making these videos

I can't understand the books being recommended. Does anyone understand the names?

The audio is quite bad.

One thing I should have focused more on is how well-designed the new features are. They fit right in. It's a great sign that the Clojure core team values design so much!

At around 17:00 on being able to pass Java methods as functions directly. I think it’s a big deal for beginners. I remember tripping on it and having to ask about it. This new way is much more intuitive.

Impressive you can do this in one take while driving. You sound just like me talking to my dictation app, but fewer pauses and less rambling.

As soon as you give up the ability to handle time, the language becomes a pain in the ass for practical applications generally. There were Lisp machines and Lisp operating systems with tagged memory.... but x86 and windows just kind of steam rolled because Intel way better at making transistors.

A maintenance disaster is what it is. It has the side effect of deferring naming things, making the code rdundant long chains of copy/pasted transformations. Tacit programming locally is OK but in the large it leads to code that is often missing the "what". Heavy de-structuring and threading macros can destroy Clojure programs quickly. It's a tool, not a religion. The greatest power we have as programmers is linguistic abstraction such that we don't need to keep rewriting the same transformations over and over but can call them by name and recreate their effects in a single line.

Sorry, Eric! Almost unwatchable because of audio cuts repeatedly!

Hi

Very impressive how you reformulated my question much clearer than I asked it. Thank you for answering!

The idea is cool. I’d add a blacklist for known VPN services. Otherwise there will be individuals who will access your site from cheapest countries. If you plan on commercializing this idea, the VPN issue might be a dealbreaker.

If a user is using a VPN can they spoof their actual country? If so, is there a way to detect this? I've seen tv.youtube.com do this kind of detection.

Your audio cuts in and out quite a bit. Seems like your microphone isn't always picking up your voice when first speaking.

Thank you

Thanks again for today!

"And you know how I know how I know that I'll prosper? 'Cause I stand here beside you today" - Ren (from Hi Ren)... about something quite different, but might be relevant here. Lisp is still around some 66 years after its initial creation... will it ever become comparatively popular? I don't know... but I kinda hope it does, and I certainly hope that people (including myself) put time in to collaborating on well-documented, welcoming, rich libraries, etc...

Tune into an exclusive interview with Binance's CEO for a sneak peek into future developments

I appreciate the video but honestly preferring a dynamically typed language is absurd. All of your complaints are that it's not a dependent total type system. So basically if you can't have a Lamborghini you don't buy a car? And for most cases quick check and quickspec get you nearly all the way there. Algebra Driven Design is a book that goes into exactly what you're talking about in haskell. Only accessible book I'm aware of that does and it relies heavily on static typing

Mark Normands brother!

That was such an awesome refactoring. Wonderful that you think out aloud so naturally.

There's a command in Calva for creating a Getting Started Project. It is branded a bit as Getting Started with Clojure, which is the main focus, but it starts with an intro to Calva. FYI.

What are those things on the walls.

thank you for doing these! always useful to see how other people do it. (the tooltip was infuriating me the whole way haha)

You can disable the hover popup in VSCode by setting "editor.hover.enabled": false in User Settings JSON.

really enjoy watching these 👍

regarding degradation, I would remember quality of an item before update, and after update. and if it's decreased after all rules applied, amplify the difference by 2 for conjured items and 1 for normal items.

8:21 - No, ANTLR is NOT a 100% solution to parsing. The fact that it's hard to use is because of all the stuff it leaves unsolved. The complexity of doing that stuff is dumped into every single application that uses ANTLR, making those applications more complex, which reinforces the need to have a giant team to maintain it. Most big frameworks in mainstream languages are 80% solutions or less. True 100% solutoins require a lot of knowledge. You have to know what problems others are running into, and your language has to allow you to solve _all_ the problems, even the ones that users unconsciously just endure without complaining. An example of a 100% solution would be CLOS with the MOP included. Or Common Lisp's condition system. A ton of research went into those. Mainstream solutions are just built ad-hoc using the easiest approach given the tools already available. Then the inevitable limitations are addressed if it's easy to do so. The real curse of Lisp is that since Lisp is so powerful and you only need a few developers, those developers end up being critical to an organization, because they're the equivalent of a big team. Therefore, firing and replacing one of those developers is like laying off an entire department and rebuilding it from the ground up. Clojure escaped the "Curse of Lisp" by being an 80% Lisp. The reason you need all those Java libraries is because Clojure is relatively weak. Common Lisp has pretty good C interop, but it's not used anywhere near as frequently as Java is in Clojure programs.

Are you going to have office hours on the 4th?

I think you make a good point. People seem to (want to) misunderstand what you are actually trying to say.

I love Lisp, but it suffers from the same types of problems that Python does. As it scales, it's just too easy to break things with mismatched types, number of arguments, etc... you have to exercise all code paths at runtime to have confidence in it. Compare that to Rust where if it compiles, it typically just works. If I was starting a company that needed to innovate very quickly, I'd use Lisp. But if I was a company that had mission critical systems that must work, but could take a little more time to get there, I'd likely use Rust.

Thank you for the string concatenation e.g. So much easier to see the motivation behind the distinction between commutativity and associativity with a simple case where one applies and the other doesn’t.

"monoids kick monads' butt" :facepalm:. Does true kick false's butt? Does 42 kick 41's butt? Is > greater-than <?

Hi Eric, FYI, the audio level is quite low compared to other KZbin content

What’s the link to submit a question? I hope to join soon but have an ongoing scheduling conflict.

Clojure is for IQ 130 ppl, Haskell is for IQ 150 ppl...

Re: formalizing a domain. That's one of the reason's Ken Iverson created APL. He wanted to use it as a new, more regular notation to teach math. Bonus points that it is executable.

7 months late to the party, this is such a weak argument I figured I’d leave a comment anyways. Comparing Haskell to a university 100 level understanding of C is such a weak argument because the people who write C don’t only have this level of understanding. I don’t know what a monad is but that doesn’t mean I can cast doubt on the fact that serious Haskell users understand monads and when to use them. The same argument can and should be made about C. This guy doesn’t roll his own data structures or import libraries, and just assumed everyone else was doing the same. Either this person is attempting to deceive people who don’t know any better, or they truly don’t understand C development, but either option shows why not to trust this line of thinking.

All the ppl coming from Prime's video apparently can't understand what is being said. Quite literally every single comment by these guys misses the point by a fucking lightyear.

Even eMacs ends up not using lisp tree sitter for eMacs is c not lisp

The main benefit I find to dynamic typing is that it can ease the process of writing and modifying code, provided we think about our data more abstractly. The major downside to me is that it opens up far more room for runtime errors and need for more comprehensive testing (potentially including validation of input types for functions), as the omission of type specification prevents many programmer mistakes from being caught at compile time. The final one to me is that dynamic typing is hopelessly less efficient than static typing for the most performance-critical of code (ex: a game engine or path tracer), since the appropriate size and precision and even alignment of a data type is not something that an optimizer can deduce absent runtime inputs. Even an optimizer that performs contorting acts analyzing IR to determine the optimal register types and instruction selection lacks the sufficient information in advance to do so anywhere close to optimally for dynamically-typed languages. So much of the added performance of statically-typed languages comes from programmers carefully and explicitly choosing the most economical data types to optimize for locality of reference, SIMD registers, to eliminate false sharing, etc.

My suspicion is that FP in general is not popular because it heavily relies on recursion, which many people find hard to grasp (once you understand it, it makes sense, but until then it's deep magic, and many fail to overcome this obstacle (monads are even worse haha)). Obviously syntax matters a lot. Why did python win over perl? LISP in particular is annoying some people because of the parentheses (this I know for a fact, given that I'm one those people haha) - you can deny it, but that doesn't disprove it. To add to that, LISP comes with some really awfully named functions for basic things: wtf is a CAR and a CDR? It sounds like total nonsense. I'm already turned off before I even started :) TBH, I've never seen anything other than toy examples written in lisp or scheme (No doubt big systems exist, I just never saw them - emacs perhaps being the sole exception) which creates the impression that "no one" is using it for "real work" or that perhaps its approach of combining small functions leads to an untractable mess of thousands of weirdly named small functions (some of which probably could be almost duplicates?) trying to build the equivalent of a million line of C++ code system. It may be easy to write, but can you still understand it 3-5-10 years down the road? Here I agree with the individualism argument: if everyone starts to introduce mini DSLs, it doesn't help someone new to the system to make sense of it all. According to google trends (is that a good source?), clojure is much LESS popular than lisp nowadays, so in retrospect the JVM argument didn't really hold up. As for the argument "Parsing in LISP is easy" - sure, if you parse lisp-like trees, since they are pre-parsed by the human typing them in. However, writing a C++ parser with semantic disambiguation most likely will not be easier in lisp than in C++ because the recursive descent parsing is not where the real difficulty lies (but I'd love to be corrected on this!).