5 ms·

i mean, is code written in lisp-like functional style maintainable? it always takes a few seconds more per line of code for it to register if it does at all...

i mean, is code written in lisp-like functional style maintainable? it always takes a few seconds more per line of code for it to register if it does at all... versus code written in say imperative or declarative style. i mean what could this possibly mean? "(bg rend &(rgb (/ @state 2) (/ @state 3) (/ @state 4))))"

detaro 7y ago
Do you really think people do not get used to brackets being in slightly different places and things being ordered slightly differently? (The ones starting with functional languages certainly do when they start using other languages later :D)
yogthos 7y ago
It seems like you're getting hung up on s-expression syntax being different than what you're familiar with. This would be akin to a native English speaker saying that Korean is completely incomprehensible. Meanwhile, a native Korean speaker would have quite a different perspective. My team used to be a Java shop, and we switched to Clojure about a decade ago. Looking back and comparing similar types of projects that we've developed in both languages there's no contest. Clojure is much faster to develop, and far easier to maintain long term. There are two fundamental problems with OOP. The first problem is that classes encourage creating ad hoc APIs. Every time you create a class with some methods, that's a unique API. Knowing how one class behaves tells you nothing about the next. As the number of classes grows, it becomes more difficult to understand what the system is doing because you have to keep all the unique behaviors in your head to reason about it. The second problem is that objects are state machines. Each object has its own internal state that gets manipulated via its methods. The states of the objects are also interdependent in most cases. So, the more objects you have at runtime, the more states you have to keep in your head to know what any one piece of code is doing at any given time. In practice, this makes it impossible to reason about code with any degree of confidence in large systems. Only thing you can do is fire up the debugger, put your application in the desired state, and then inspect it. Reasoning about code becomes a heuristic at that point. You can test it for some specific cases, and hope that it will work for all cases, but you can never really know that it will. FP and immutability tackle both of these problems head on. Immutable data directly leads to the ability to do local reasoning about your code, and allows you to write pure functions that can be reasoned about independently. Meanwhile, data is not being abstracted inside opaque state machines that provide ad hoc DSLs as their API. Instead, it's explicitly passed through function pipelines to transform it. These aspects make the code much easier to understand and maintain because you can look at a specific part of the application and reason about its behavior in isolation.
- vincent-toups 7y ago
  A few things about the functional/oo divide became clear to me as I was implementing my last game, which I wrote more or less from scratch in Scheme using a hybrid of functional and object oriented systems. One important lesson is that Object Orientation tends to produce a bit of conceptual dissonance in new programmers. It seems to tell you that the solution to your problem is identifying the objects you're interested in and then translating that set of objects into code. This is almost never the optimal design. Typically a completely different set of objects needs to be implemented and then composed into your program. Objects fundamental to the domain of interest may not even appear as single objects in the implementation. A lot of what people complain about w.r.t. OO programming is just related to inexperience, in other words. Functional programming, on the other hand, asks you to construct your program out of much more fundamentally abstract pieces. There is less of a chance that you'll naively sally forth implementing your mental model directly. To some extent, that accounts for its nice properties.
vincent-toups 7y ago
I prefer s-expressions, for what its worth, to almost any syntax. I've also been programming in Lisp dialects for more than a decade, so I've had time to get used to them. But I still find them more readable than any other kind of language.
- NikkiA 7y ago
  Same, it's just less ambiguous than anything else.
- vnorilo 7y ago
  And more writable, since your editor can take advantage of the consistent structure via paredit et al. FWIW, I split my time 2:1 between C++ and Clojure these days, and the context switch to s-exprs is always easier, even though I spend less time working in them.

detaro 7y ago

Do you really think people do not get used to brackets being in slightly different places and things being ordered slightly differently? (The ones starting with functional languages certainly do when they start using other languages later :D)

yogthos 7y ago

It seems like you're getting hung up on s-expression syntax being different than what you're familiar with. This would be akin to a native English speaker saying that Korean is completely incomprehensible. Meanwhile, a native Korean speaker would have quite a different perspective. My team used to be a Java shop, and we switched to Clojure about a decade ago. Looking back and comparing similar types of projects that we've developed in both languages there's no contest. Clojure is much faster to develop, and far easier to maintain long term. There are two fundamental problems with OOP. The first problem is that classes encourage creating ad hoc APIs. Every time you create a class with some methods, that's a unique API. Knowing how one class behaves tells you nothing about the next. As the number of classes grows, it becomes more difficult to understand what the system is doing because you have to keep all the unique behaviors in your head to reason about it. The second problem is that objects are state machines. Each object has its own internal state that gets manipulated via its methods. The states of the objects are also interdependent in most cases. So, the more objects you have at runtime, the more states you have to keep in your head to know what any one piece of code is doing at any given time. In practice, this makes it impossible to reason about code with any degree of confidence in large systems. Only thing you can do is fire up the debugger, put your application in the desired state, and then inspect it. Reasoning about code becomes a heuristic at that point. You can test it for some specific cases, and hope that it will work for all cases, but you can never really know that it will. FP and immutability tackle both of these problems head on. Immutable data directly leads to the ability to do local reasoning about your code, and allows you to write pure functions that can be reasoned about independently. Meanwhile, data is not being abstracted inside opaque state machines that provide ad hoc DSLs as their API. Instead, it's explicitly passed through function pipelines to transform it. These aspects make the code much easier to understand and maintain because you can look at a specific part of the application and reason about its behavior in isolation.

vincent-toups 7y ago
A few things about the functional/oo divide became clear to me as I was implementing my last game, which I wrote more or less from scratch in Scheme using a hybrid of functional and object oriented systems. One important lesson is that Object Orientation tends to produce a bit of conceptual dissonance in new programmers. It seems to tell you that the solution to your problem is identifying the objects you're interested in and then translating that set of objects into code. This is almost never the optimal design. Typically a completely different set of objects needs to be implemented and then composed into your program. Objects fundamental to the domain of interest may not even appear as single objects in the implementation. A lot of what people complain about w.r.t. OO programming is just related to inexperience, in other words. Functional programming, on the other hand, asks you to construct your program out of much more fundamentally abstract pieces. There is less of a chance that you'll naively sally forth implementing your mental model directly. To some extent, that accounts for its nice properties.

vincent-toups 7y ago

I prefer s-expressions, for what its worth, to almost any syntax. I've also been programming in Lisp dialects for more than a decade, so I've had time to get used to them. But I still find them more readable than any other kind of language.

NikkiA 7y ago
Same, it's just less ambiguous than anything else.
vnorilo 7y ago
And more writable, since your editor can take advantage of the consistent structure via paredit et al. FWIW, I split my time 2:1 between C++ and Clojure these days, and the context switch to s-exprs is always easier, even though I spend less time working in them.