Earlier quoted context omitted.
You really should be using a logging framework instead though, if you're working on a large application.
... which you can build using a LoggingFrameworkFactory.
Why I love Common Lisp and hate Java (2012)
51–60 of 171 posts
Re: Why I love Common Lisp and hate Java (2012)
#52Earlier quoted context omitted.
Whats even better than print for debugging is using a debugger...
I disagree. Most of the time, I find a debugger just slows me down. It's super helpful in some cases, but good logs can pinpoint problems far before a debugger can. Also, building in debug mode can change everything, so you may not even catch your bug, especially if it's concurrent in nature.
1st you have to add the useless print statements and after decades of programming a debugger is vastly superios in terms of 'debugging' when compared to printing. (Back in time basic had no debugger even)
Also printing is utterly useless for high concurrent code, as printing alters memory visibility, usually adds global sync, etc..
Re: Why I love Common Lisp and hate Java (2012)
#53Earlier quoted context omitted.
You use logging for production, but if you just want to see what a value is while when you run your program in the IDE and might not for a logger imported, print is handy.
If you're running from an IDE and want to inspect values, why not just set a breakpoint?
Re: Why I love Common Lisp and hate Java (2012)
#54Re: Why I love Common Lisp and hate Java (2012)
#55Re: Why I love Common Lisp and hate Java (2012)
#56Beside the REPL, another impressive feat of Common Lisp is meta-programming. You can write software to write software. Say what? Yeah, that was my initial reaction too, but Common Lisp’s macro system allows you to write functions that return code snippets. It completely redefines the word. Or more accurately, re-redefines, since Lisp is much older than MS Office, which is what most people associate macros with, sadly…
That being said, I write Java for a living, and I don't find it terribly verbose, outside of the lack of sum types, pattern matching, and typeclasses.
Re: Why I love Common Lisp and hate Java (2012)
#57Earlier quoted context omitted.
I think there are two use cases here, I was referring to debugging during development and a lot of replies are regarding troubleshooting an active prod system. Of course we all hope for well thought out logging to troubleshoot issues we're seeing in prod. I'm referencing an pattern I see with junior devs who simply use "printf debugging" in development instead of learning to use a debugger properly, even with distrib…
> an pattern I see with junior devs who simply use "printf debugging" in development Whereas I see this pattern more with senior engineers.
Get on my level, normies. /s
Re: Why I love Common Lisp and hate Java (2012)
#58It is a recurring theme for people to point out how verbose a hello world program is in Java: class HelloWorldApp { public static void main(String[] args) { System.out.println("Hello World!"); } } For argument sake, let's compare it not to Lisp but to Python instead: print("Hello World!") Once you get proficient in a language and start writing larger programs, your perspective can change entirely. What appears to be…
On the other hand,
"__name__ == __main__" is just a convenience for debugging and small scripts. I wouldn't use it in real programs.
I dont use @staticmethod, or find it useful. If I want a function, I use a function.
Re: Why I love Common Lisp and hate Java (2012)
#59It is a recurring theme for people to point out how verbose a hello world program is in Java: class HelloWorldApp { public static void main(String[] args) { System.out.println("Hello World!"); } } For argument sake, let's compare it not to Lisp but to Python instead: print("Hello World!") Once you get proficient in a language and start writing larger programs, your perspective can change entirely. What appears to be…
> In Java the top level only contains classes and interfaces. This design makes sense from conceptual purity, but Java is never a conceptually pure language. It distinguishes value types and object types, for instance. Not allowing free functions is really just a poor design choice. Worse, the proliferation of single-method interfaces (which are really just functions) and static methods (which are in most cases reall…
I don't see why. The verbosity is pretty minimal and you enforce the availability of a privacy scope you wouldn't have had. ie private static methods and members that your public statics can use.
Although, pure functions are nice if you can't trust the code you're calling won't surprise you.