3 ms·

For me a language is getting close to "powerful enough" when it does not get in the way of you as the programmer when you are developing abstractions of the for

by Guthur 14y ago

For me a language is getting close to "powerful enough" when it does not get in the way of you as the programmer when you are developing abstractions of the form that seems most natural to you. This can cause problems in some cases; when the language is stepping that far back to allow you the freedom then it is up to your to enforce your own constraints to avoid your abstractions becoming...too abstract (maybe). Also in my opinion there is not one abstraction form that will appeal to every type of programmer. For me I like the freedom to manipulate and define symbolic forms with Common Lisp for others it might be the expressive type system of the Haskell. I don't think you can truly say one way is better than the other. I think those languages and a few others are giving the tools of abstraction that will not get in the way of you as the programmer.

SomeCallMeTim 14y ago
>enforce your own constraints to avoid your abstractions becoming...too abstract (maybe). Too abstract isn't necessarily the problem. When I've stepped too far away from standard OO structure, the problem typically becomes organization. In OO you know where just about everything SHOULD be, at least. If you're writing your own rules, it's harder to be certain where new variables get set, or what members you should find in what structures. It takes a certain level of discipline to not shoot yourself in the foot. Or at least to clean things up before they get too messy.
- Guthur 14y ago
  Depending on the implementation of the OO system in question it could provide you with relatively limited options for abstraction. I can only really speak from a Common Lisp point of view and the problem there that I was alluding to is the fact that you are so free to produce your own forms of abstractions whether it be mini DSL macros, dynamic dispatch method combinations, data driven programming using first class functions etc. that if you are not careful you can easily obfuscate the real intention rather than making it clearer.
  - SomeCallMeTim 14y ago
    I use Lua, with ALLOWS you to use OO, but doesn't enforce it. To say the least. Lua does have first-class functions, including full closures, and the one Lua data structure is a "table", which can act like a full OO class with the right patterns applied, but which generally can be extended anywhere, each "object instance" getting its own unique extra fields attached. Lua doesn't have macros (well, you can use a library to get an extremely powerful macro language if you want [1]), but the problem with going too far down the macro/DSL route (IMHO) is that the code becomes harder for people who didn't write it to understand. Or even if the code itself is easy to understand (by virtue of being a good DSL), it becomes harder to extend or modify, especially if the modification involves something not explicitly designed for by the original developer. If you stick with the syntax of a known and well documented language, then the learning curve for new developers is easier. Though even then, the other issues you point out can obscure the code flow, so probably the only thing you can say is that complex code is complex. ;) [1] http://metalua.luaforge.net/ http://metalua.luaforge.net/

by Guthur 14y ago

SomeCallMeTim 14y ago

>enforce your own constraints to avoid your abstractions becoming...too abstract (maybe). Too abstract isn't necessarily the problem. When I've stepped too far away from standard OO structure, the problem typically becomes organization. In OO you know where just about everything SHOULD be, at least. If you're writing your own rules, it's harder to be certain where new variables get set, or what members you should find in what structures. It takes a certain level of discipline to not shoot yourself in the foot. Or at least to clean things up before they get too messy.

Guthur 14y ago
Depending on the implementation of the OO system in question it could provide you with relatively limited options for abstraction. I can only really speak from a Common Lisp point of view and the problem there that I was alluding to is the fact that you are so free to produce your own forms of abstractions whether it be mini DSL macros, dynamic dispatch method combinations, data driven programming using first class functions etc. that if you are not careful you can easily obfuscate the real intention rather than making it clearer.
- SomeCallMeTim 14y ago
  I use Lua, with ALLOWS you to use OO, but doesn't enforce it. To say the least. Lua does have first-class functions, including full closures, and the one Lua data structure is a "table", which can act like a full OO class with the right patterns applied, but which generally can be extended anywhere, each "object instance" getting its own unique extra fields attached. Lua doesn't have macros (well, you can use a library to get an extremely powerful macro language if you want [1]), but the problem with going too far down the macro/DSL route (IMHO) is that the code becomes harder for people who didn't write it to understand. Or even if the code itself is easy to understand (by virtue of being a good DSL), it becomes harder to extend or modify, especially if the modification involves something not explicitly designed for by the original developer. If you stick with the syntax of a known and well documented language, then the learning curve for new developers is easier. Though even then, the other issues you point out can obscure the code flow, so probably the only thing you can say is that complex code is complex. ;) [1] http://metalua.luaforge.net/ http://metalua.luaforge.net/