3 ms·

I have never used Crystal before, but I don't understand how you can be against "everything is an object" and then say Python and Javascript are different... Pr

I have never used Crystal before, but I don't understand how you can be against "everything is an object" and then say Python and Javascript are different... Pretty much everything in Python and JS is an object... So really, what does fundamentally differ?

Shoothe 9y ago
> Pretty much everything in (...) JS is an object Except primitives that are not objects but (some) can be autoboxed to behave like objects. A riddle: var a = 2; a.b = 3; console.log(a.b);
nnq 9y ago
> So really, what does fundamentally differ? Sure, one can argue that nothing ever fundamentally differs because all languages are Turing complete, but... When I decide to use functions in a language that has objects, 99% of the time it is implied that a function either 1. holds no state, aka "referential transparency" 2. if it manages external state, it does it by modifying one of its arguments (usually the first one and in a very obvious way) This allows nice mixing of functional and OOP! ("mixing" by keeping things separate, paradoxically :P...) I know that if I see a piece of code with a dance of functions that take in and/or generate functions etc., that's a "functional zone" of a program and those function obviously don't have state. When the only way of passing functions to functions and returning them is basically the same thing as passing and returning objects, you'll always be lost when reading someone else code and have to ask yourself at every step: "is that thing that receive the `.call` message maybe also holding some state". Or you'll always be unable to just assume that a function is referentially transparent, because "it's OOP, object aren't RT, dooh". This places a huge mental burden when reading/understanding other people's code! (And yes, in Python or JS you can also treat functions like objects and even attach fields and methods to them, BUT there is no not-extremely-awkward or obvious way to mutate those from code inside the function. Referring to the function by name makes it obvious. Using stuff like `arguments.caller` is awkward and widely accepted as bad practice. Only static variables in C++ allow such "muddying the semantic waters" practice easily, but they are also bad practice and easy to grep for.)

Shoothe 9y ago

> Pretty much everything in (...) JS is an object Except primitives that are not objects but (some) can be autoboxed to behave like objects. A riddle: var a = 2; a.b = 3; console.log(a.b);

nnq 9y ago

> So really, what does fundamentally differ? Sure, one can argue that nothing ever fundamentally differs because all languages are Turing complete, but... When I decide to use functions in a language that has objects, 99% of the time it is implied that a function either 1. holds no state, aka "referential transparency" 2. if it manages external state, it does it by modifying one of its arguments (usually the first one and in a very obvious way) This allows nice mixing of functional and OOP! ("mixing" by keeping things separate, paradoxically :P...) I know that if I see a piece of code with a dance of functions that take in and/or generate functions etc., that's a "functional zone" of a program and those function obviously don't have state. When the only way of passing functions to functions and returning them is basically the same thing as passing and returning objects, you'll always be lost when reading someone else code and have to ask yourself at every step: "is that thing that receive the `.call` message maybe also holding some state". Or you'll always be unable to just assume that a function is referentially transparent, because "it's OOP, object aren't RT, dooh". This places a huge mental burden when reading/understanding other people's code! (And yes, in Python or JS you can also treat functions like objects and even attach fields and methods to them, BUT there is no not-extremely-awkward or obvious way to mutate those from code inside the function. Referring to the function by name makes it obvious. Using stuff like `arguments.caller` is awkward and widely accepted as bad practice. Only static variables in C++ allow such "muddying the semantic waters" practice easily, but they are also bad practice and easy to grep for.)