Re:We need visual programming. No, not like that
by brabel on Monday July 15, 2024 @06:55AM
(#40966728)
Common Lisp has always allowed you to specify types anywhere you want. It's not a statically typed language but it supports types (and SBCL and other impls do static checking where possible).
Re:We need visual programming. No, not like that
by CharlieDigital on Monday July 15, 2024 @07:22AM
(#40966839)
I think that OOP done right can address this problem through encapsulation of the logic.
One can make the case that a function can do the same. I agree, but a class is just a container for a set of related functions and state.
The problem with OOP seems to be that as a whole, devs are not that great at encapsulation and isolating domain logic.
Re:We need visual programming. No, not like that
by patrickmay on Monday July 15, 2024 @10:10AM
(#40968047)
The number of codebases I've worked on where developers automatically added getters and setters for all class members is too damn high.
Re:We need visual programming. No, not like that
by pgris2 on Monday July 15, 2024 @10:57AM
(#40968432)
So, paraphrasing:
Any sufficiently complicated Ruby program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Java
Re:We need visual programming. No, not like that
by tdbgamer on Monday July 15, 2024 @11:08AM
(#40968534)
I guess the upside is that you end up with a "compiler" that checks the invariants of your project and that domain rather than strict type safety. I love static typing, but I did try Elixir w/ Phoenix recently and was impressed that they were able to implement compile time checks like verifying that all redirects are valid routes, etc. Depending on what you're building, having a few small domain specific checks like that could be more valuable than strict type safety.
Eventually they did the same thing you can do in common lisp: Add so much metaprogramming that doublechecks invariants, it might as well be a compiled language.