5 ms·

A lot of it boils down to types--the difference between a labeled and an unlabeled cadaver. One has a little tag next to the vein with "blood, to heart" writt

A lot of it boils down to types--the difference between a labeled and an unlabeled cadaver. One has a little tag next to the vein with "blood, to heart" written on it, the other is just an empty tube. What was in the tube? Which way did it flow? I'll have to probe it with the REPL to find out. While with rust, or go, or even c, i have a type instead of another list, i can browse to its definition in a click--a lookup instead of an investigation. The cultists are all crying, "you suck at naming! you suck at comments!" And maybe I do! But those 12 people who will have to maintain it are going to suck even more. That's where a more "blub-like" language shines. It is enforcing a standard. And the cultists cry again, "i'm so smart i don't need blub to hold my hands!" Ok, if you say so... but where is your Minecraft (blub)? where is your Excel (blub)? where is your Facebook or your Google (blub)? maybe we can just accept that lisp is nice in some places, but not so nice for others?

anonzzzies 2y ago
So you mean to say; it takes 2x as long to get into not statically typed lang code? Asm? I mean sure it’s typed but… And we are pro static types, it’s just easier to add them after I am done experimenting. Not upfront. And we do via various (backward compat) custom CL constructs and provers.
- hello_computer 2y ago
  types are just an example. structure (modules/classes/keywords/constructs) is also a big win for organization and assisted code navigation. even with dynamic types, i find it far easier to grep a python codebase than a lisp one. is it code? is it data? python syntax makes it fairly clear.
  - anonzzzies 2y ago
    Fair enough; can’t say I have this experience but that’s fine; I am not religious. Although I would say, unless you are doing a lot of things with macros (hint; you shouldn’t and where you do, it should be clearly indicated; Ruby suffers from this as well when reading code imho) otherwise it seems very strange the code/data barrier isn’t immediately clear. But maybe I don’t hang as much on syntax as others do (we our own k3 to lisp to CUDA for some things and I don’t find it different/more difficult to read).
g00z 2y ago
I'm curious if these problems are more about flexibility. Because I find with any well designed and flexible program in a statically typed language, you end up with the same "tube of something" as you have in your dynamic language examples. Take any large generic framework in rust, the types are extremely generic, dispatching on more generic traits. It's hardly a tag that says: "blood, to heart" unless it is highly coupled and working in one area.
- hello_computer 2y ago
  > generic framework Yet at some point, the template is instantiated--in the text!--and you can fill-in-the-blank by reading instead of having to do a runtime probe. For large systems that have a lot of preconditions, the "runtime probe" approach can be a thick fat time-waster (i.e. caressing the program into a state where something is even in the tube).
  - g00z 2y ago
    But do you really think the runtime probe is less effective in an environment where you have a good way of interacting with the program at runtime? Or is it just bad tools tainting the experience? Because I find that in a good dynamic environment, it's easier to figure out how to use something complex when compared to trying to uncover how and why the types line up. The absolute extreme being something like smalltalk, where you just guess how it should be used and then fix it in the debugger until it works.
    - The_Colonel 2y ago
      > But do you really think the runtime probe is less effective in an environment where you have a good way of interacting with the program at runtime? No matter the tool, it will be very difficult to try out all code paths to figure out what can be in that tube. The difficulty scales with the size / age of the application. Take your typical 20 years old enterprise application. Nobody from the original team is around. Whole generations of programmers worked on the project, each with their own favorite patterns / code style / level of diligence. There's a massive amount of features, half of which you don't even know about. Test coverage is spotty at best. You see some common function triggered from hundreds of places, it makes a huge difference in your ability to reason about it if you have types on the data being processed or not.

anonzzzies 2y ago

So you mean to say; it takes 2x as long to get into not statically typed lang code? Asm? I mean sure it’s typed but… And we are pro static types, it’s just easier to add them after I am done experimenting. Not upfront. And we do via various (backward compat) custom CL constructs and provers.

hello_computer 2y ago
types are just an example. structure (modules/classes/keywords/constructs) is also a big win for organization and assisted code navigation. even with dynamic types, i find it far easier to grep a python codebase than a lisp one. is it code? is it data? python syntax makes it fairly clear.
- anonzzzies 2y ago
  Fair enough; can’t say I have this experience but that’s fine; I am not religious. Although I would say, unless you are doing a lot of things with macros (hint; you shouldn’t and where you do, it should be clearly indicated; Ruby suffers from this as well when reading code imho) otherwise it seems very strange the code/data barrier isn’t immediately clear. But maybe I don’t hang as much on syntax as others do (we our own k3 to lisp to CUDA for some things and I don’t find it different/more difficult to read).

g00z 2y ago

I'm curious if these problems are more about flexibility. Because I find with any well designed and flexible program in a statically typed language, you end up with the same "tube of something" as you have in your dynamic language examples. Take any large generic framework in rust, the types are extremely generic, dispatching on more generic traits. It's hardly a tag that says: "blood, to heart" unless it is highly coupled and working in one area.

hello_computer 2y ago
> generic framework Yet at some point, the template is instantiated--in the text!--and you can fill-in-the-blank by reading instead of having to do a runtime probe. For large systems that have a lot of preconditions, the "runtime probe" approach can be a thick fat time-waster (i.e. caressing the program into a state where something is even in the tube).
- g00z 2y ago
  But do you really think the runtime probe is less effective in an environment where you have a good way of interacting with the program at runtime? Or is it just bad tools tainting the experience? Because I find that in a good dynamic environment, it's easier to figure out how to use something complex when compared to trying to uncover how and why the types line up. The absolute extreme being something like smalltalk, where you just guess how it should be used and then fix it in the debugger until it works.
  - The_Colonel 2y ago
    > But do you really think the runtime probe is less effective in an environment where you have a good way of interacting with the program at runtime? No matter the tool, it will be very difficult to try out all code paths to figure out what can be in that tube. The difficulty scales with the size / age of the application. Take your typical 20 years old enterprise application. Nobody from the original team is around. Whole generations of programmers worked on the project, each with their own favorite patterns / code style / level of diligence. There's a massive amount of features, half of which you don't even know about. Test coverage is spotty at best. You see some common function triggered from hundreds of places, it makes a huge difference in your ability to reason about it if you have types on the data being processed or not.