161–170 of 171 posts
Earlier quoted context omitted.
Only with python. With LISP it's the common case to debug prod. I would rather argue that such incompetent managers who speak such nonsense need to be fired.
Smalltalk folks will debug in production too. Although to be fair, Smalltalk folks will write whole programs in debug in development.
Earlier quoted context omitted.
You're really underestimating the power of Java's boring workhorse methodology. If you're looking for love there's a lot of other languages that are more pure and more beautiful for certain use cases. However, there's a reason Java is in the top 3 most popular languages. Its pragmatic, it scales, it plays nice with tooling and the language itself is pretty passable.
I'm not asking for anything fancy - just an example of a Java codebase that is "good" for whatever definition of "good". I'm currently dabbling in Android development, and the few Java libraries I've dealt with, especially Android's own APIs, have been a thorough exercise in frustration, to put it mildly. Where are the good Java codebases hiding?
Have you looked at JDK itself?
Earlier quoted context omitted.
I think this has to do with naming. Naming is generally hard, with free functions you must name the function, in Java you must also name the class. If you could show some examples of single method interfaces whose naming makes sense, I'd be delighted!
>If you could show some examples of single method interfaces whose naming makes sense, I'd be delighted! IDisposable with a single Dispose() method?
Earlier quoted context omitted.
What fundamentally different does Groovy offer? What do you mean by "Scala is trying to compete on Java's home turf"?
Groovy is a truly dynamic language (with all the pros and cons that come with that). So you can put it into contexts such as interactive scripting where Java will always be suboptimal and solve problems Java doesn't even want to solve. On the other hand, every single good idea that Scala comes up with will eventually be co-opted by Java, because there is no reason for that not to happen. It is just a matter of time.
Earlier quoted context omitted.
Implementing async/await. You can accomplish that entirely via macros in Common Lisp, whereas in Java you would need to do bytecode transformation via a javaagent (which, shockingly, I just discovered somebody has actually done: https://github.com/electronicarts/ea-async ). 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 typecla…
Isn't that really hard to implement correctly in Common Lisp? Your macro would need to perform a continuation-passing style transformation on arbitrary code that could involve jumps, error, etc.
Earlier quoted context omitted.
Groovy is a truly dynamic language (with all the pros and cons that come with that). So you can put it into contexts such as interactive scripting where Java will always be suboptimal and solve problems Java doesn't even want to solve. On the other hand, every single good idea that Scala comes up with will eventually be co-opted by Java, because there is no reason for that not to happen. It is just a matter of time.
When higher kinded types come to Java, please ring me up!
Earlier quoted context omitted.
Attaching a debugger will also change the behavior of concurrent code.
This would depend on the language/compiler/linker - take Java (which the article is about). Attaching debugger does nothing prior to adding a breakpoint. The breakpoint would cause the method to be deoptimized, executed in the interpreter. Removing the breakpoint would allow the method to be optimized again. Now obviously during stepping in, the thread would be blocked and not highly concurrent. However print stateme…
Earlier quoted context omitted.
Isn't that really hard to implement correctly in Common Lisp? Your macro would need to perform a continuation-passing style transformation on arbitrary code that could involve jumps, error, etc.
You don't need to do CPS transformations if your language supports first class continuations. Lookup `call/cc`
Earlier quoted context omitted.
> I dont use @staticmethod, or find it useful. If I want a function, I use a function. In principle, it makes sense to "bundle" functions that are strictly related to a class within the class itself (i.e. as static methods). Of course, the benefits viz. top-level functions are only noticeable if your codebase is big enough.
What are those benefits?
But again, they are "usability" benefits. I'm no CPython expert but I don't think that a static method would have noticeably worse (or better) performance than a function.
Earlier quoted context omitted.
Java has been gradually eating all the good parts of Scala. So far, it's eaten lambdas, map / reduce / fold functions, option types, raw string literals, the concept of a built-in REPL, type inference for local variables, and default methods in interfaces (which is kind of like mixins). Pattern matching and type classes are on the menu, but not yet formally merged into Java. So what does Scala have left? Operator ove…
> Java has been gradually eating all the good parts of Scala. So far, it's eaten lambdas, map / reduce / fold functions, option types, raw string literals, the concept of a built-in REPL, type inference for local variables, and default methods in interfaces (which is kind of like mixins). If you adopted Scala 5 years ago, you could have had all the good stuff Java has today, 5 years ago. If you adopt Scala today you…
That's not even in the top 5 problems with operator overloading.
> How many years or decades will those "formalities" take? Java language > enhancements have a history of taking much longer than originally claimed.
Almost certainly a shorter amount of time than it would take to migrate our codebase away from Java. Oracle has actually been moving pretty fast with Java recently, for better or worse.
> [XML is...] Already moved into an optional library, being dropped entirely in > the next version.
And this illustrates another problem: Scala is constantly breaking backwards compatibility. Which is a real-world problem, unlike "I want the latest gee-whiz language feature."
> Put that together and you get a language where you never need the magical > frameworks that (real-world) Java needs.
Scala has plenty of "magical frameworks": scalaz, akka, shapeless, the list goes on.
Newer Java libraries like Jackson don't need a type registry (or at least, not one that have to manually set up.)
I won't try to defend J2EE or Hibernate, but also, I don't use them.