incepted

34 ms·

301.
by incepted 11y ago
That's pretty much unavoidable for complex problems. What you want to do is make sure you don't need another 300 lines to implement that problem, or that if you do, that code is easy to read and to maintain.
302.
by incepted 11y ago
> Larry Wall is a linguist, and I think that is probably what sets perl apart more than anything. He's also pretty good at telling jokes, which explains a lot of things about Perl ;-)
303.
by incepted 11y ago
None of these links cover what I was discussing. The closest is part 4 ("restarting") but this section only describes code that can retry after a failure. I was specifically talking about debuggers that let you rerun code after yo
304.
by incepted 11y ago
> Smalltalk and Lisp both support this. Interesting, do you have a few pointers?
305.
by incepted 11y ago
"I" makes me think you've only ever worked solo on Clojure projects, is that correct?
306.
by incepted 11y ago
And you are falling prey to the Nirvana fallacy [1]. Yes, we will never be able to prove that a program is 100% correct but that doesn't mean we shouldn't prefer solutions that bring that number up (statically typed languages) ove
307.
by incepted 11y ago
> With dynamic typing you're much more likely to break things up early precisely because you know you have to keep things in your head. If you are programming with a language that forces to keep everything in your head, you'll
308.
by incepted 11y ago
The JVM has supported the kind of environment you describe for more than a decade. Fire up IDEA or Eclipse, put a break point in your code and modify it at runtime at your heart content. You can even rerun portions of your code after you&#x
309.
by incepted 11y ago
And nobody uses it (besides, Scala is in decline too).
310.
by incepted 11y ago
Reread the article. It doesn't say such language will not emerge (I certainly hope people keep creating languages all the time), it says they will not be successful.
311.
by incepted 11y ago
It's obvious you think it's absurd and given your heavy involvement in Clojure, your reaction is not unexpected. But you are still not addressing the main claim of the articles (that no new dynamically typed language will ever eme
312.
by incepted 11y ago
> Forgive my skepticism, but Mr. Thiel did not offer to live near a reactor. Living next to a coal plant is even more dangerous than a nuclear plant, are you suggesting we should ban both plants based on these considerations?
313.
by incepted 11y ago
They have won in theory: they are arguably better in every way than dynamically typed languages (DTL) in the sense that they offer all the advantages that used to be unique to DTL and, obviously, also all the advantages of STL (automatic re
314.
by incepted 11y ago
The author of the article seems to be essentially looking for Kotlin (except for the structural typing part, which is a terrible idea and which Kotin thankfully ignored).
315.
by incepted 11y ago
> Why should any exceptions not be checked? Because there are exceptions you can't do anything about (e.g. OutOfMemoryException) and exceptions that you don't know what to do with (e.g. an NPE where you didn't expect it).
316.
by incepted 11y ago
Most large companies in Silicon Valley give men between four and eight weeks of paternity leave, which you can take any time you want (not just right after the baby is born).
317.
by incepted 11y ago
> If I were in his shoes, I'd sell my shares in that website Probably why you're not.
318.
by incepted 11y ago
> it just moves it to somewhere else. That's exactly the point: not everyone along the method stack is forced to deal with it, only the one caller that knows how to handle it. > The problem is that I don't know where it shou
319.
by incepted 11y ago
If you don't know how to handle an exception, just add it to your `throws` clause and let a caller handle it. That's the whole point of exception: letting you choose who is the most appropriate to handle the error. Return value er
320.
by incepted 11y ago
But you have to write the `catch` (or a `throws`). That's the point. Now if you choose to handle this stupidly, that's entirely your fault, but at least the compiler did its jobs by forcing you to think about the error case. In Go
321.
by incepted 11y ago
> Just write your Java code without a try/catch block anywhere You can't. I don't think you understand how checked exceptions work.
322.
by incepted 11y ago
> In general, Go strongly encourages being explicit about errors. That's completely incorrect: it's trivial (and common) to just ignore errors in Go: ok, _ := Foo() Checked exceptions don't let you get away with
323.
by incepted 11y ago
No, it doesn't really make much sense. The diamond dependency problem only happens when two indirect dependencies are identical but on different versions and that these two versions are incompatible. That's two big if's. 99%
324.
by incepted 11y ago
It's unproven because nobody uses it and nobody uses it because it's unproven.
325.
by incepted 11y ago
The HP-41 was fascinating for an obscure reason called "synthetic programming". It was a series of key presses and operations that unlocked a mode in the calculators that allowed you to do all kinds of things that were never allow
326.
by incepted 11y ago
No tool support? Kotlin and Ceylon both have very good IDE plug-ins that already work much better than Scala, despite Typesafe pouring a lot of money into their own plug-in.
327.
by incepted 11y ago
> Scala provides the best support for strong, static typing on the JVM I'd argue that Ceylon and Kotlin offer most of Scala's advantages with none of its baggage and bloat. And drama.
328.
by incepted 11y ago
Actually Scala uses =>, so Java went the opposite way. Kotlin also uses ->. Doesn't matter much in the long run, you'll get used to whichever your language favors after just a few days or writing code in it.
329.
by incepted 11y ago
Ugh, no. Skip Scala, which is on the decline and headed fast toward obsolescence, and pick a post-Scala language such as Kotlin or Ceylon.
330.
by incepted 11y ago
Actually, your way is awfully more verbose, but you didn't notice it because you ellipsized the verbosity. If you actually take the time to translate OP's code with your own, you will soon find yourself indented six levels with

More ›