I wasn't talking generally but I'm interested to hear about any purported benefits of conflated responsibilities.
411 karma · joined September 29, 2011
If you're unfamiliar with programming language idioms, it is likely that your (ultimate, approved) contribution may not be be worth the time and the effort that has been put into guiding you to it. The help may instead have been given to you in hopes that it will pay off with your future contributions. If your only or main motivation is to learn a programming language, there's a greater chance that there won't be any.
Contributing out of sheer sense of obligation is hard. Even worse, it may so happen that you realize that you don't even like the language. Not only is the the time invested in teaching you the project a waste for the project, but the teaching you the language was not beneficial for other projects written in the same language. To stay interested in a project, you should be certain of your interest in some thing intrinsic to the project.
At least be very frank and clear about your intentions.
>[code review feedback] is like getting a free-of-cost personal guidance about how to write good code
It's not free for the reviewer who's trying to safeguard project quality. If they're investing in you, it's likely under the assumption that you'll contribute back. If you don't, then you're just crowdsourcing and then running off with the ill-gained knowledge, possibly having had a negative impact on the project.
That's GPL enforcement.
This is mostly how FSF, SFLC et al do it and they win battles. Recently they're actually waging a legal one against VMWare but I don't see the company deterred from contributing as much as they did before. Would be nice if they contributed more.
I don't think we should care about proprietary makers' feelings here. What hurts free software more is FUD and villification of copyleft.
That's all the convincing I'd ever need. Though having a built-in optionally-persistent B-tree-based store sounds interesting.
Please refer to the quote from the license I've provided, and belorn's thought experiment here.
As for whether it's more readable, I'm skeptical: It may save you going through some of the condition, but I believe getting used to it would make you more likely to overlook parts of the condition. Plus, the way it reads is the opposite of how you'd say what it does in English.
F̶i̶n̶a̶l̶l̶y̶,̶ ̶o̶b̶s̶c̶u̶r̶e̶ ̶a̶r̶c̶h̶i̶t̶e̶c̶t̶u̶r̶e̶s̶ ̶m̶a̶y̶ ̶d̶e̶f̶i̶n̶e̶ ̶a̶ ̶n̶o̶n̶-̶z̶e̶r̶o̶ ̶N̶U̶L̶L̶ (see to3m's reply). Using NULL makes it easier to find null pointer checks and conveys semantics (pointer vs integer).
Details at https://www.gnu.org/licenses/license-list.html#NASA
Pay me
I don't know what number crunching web applications the vendors are thinking of. I want wasm for client-side web programming without JS.
I believe it would. Agreeing on the objective would allow us to understand the situation-dependent trade-offs, and help us to agree to disagree on subjective.
>> Conversely, it is not a matter of opinion that dynamic languages allow patterns that static typing does not (eg. duck typing[sic]).
>Not a very good example, actually there are static type systems which use structural typing to allow for type-safe duck typing. Examples are Opa with its Power Rows, OCaml with its polymorphic variants and others.
As you've said, it's still static typing, whether the types are explicit or not. Duck typing allows things to learn to quack at runtime, structural typing doesn't enable that.
>in the worst case you can write an intepreter
If you create a dynamic language, then you're using a dynamic language. Please no more Turing equivalence.
>Given that, per the paper above, we have no hard data on how exactly static typing (much less on a dynamic typing techniques...) affects the metric we're interested in, the answer to the question is - again - a matter of personal opinion.
I'm sure there is some hard data somewhere. But I like strong indications as well to decide what may be worth investigating.
>> These are objective arguments we can discuss, and weigh against each other. There are even studies that we can throw in here.
>I'm sorry, but I'd like to trouble you to provide such papers; as you can see above my quick search returned somewhat different results.
I thought I could humor you relatively easily, but my results matched yours - conclusive research on the general question seems elusive (see eg https://danluu.com/empirical-pl/). I cede the point, I'll try to pay more attention from now on.
>The trend of "mainstream" moving to static typing is visible, but it's important to note that the same trend was observed more than once in programming history already. In all the previous cases it reversed (to dynamic typing) after ten to fifteen years.
"Reversal" here seems to imply a return to a default. On the contrary, I can't say definitely that there was a time when dynamic languages ruled the mainstream.
>Your original thesis was that static typing is an overall win over dynamic typing. I already managed to convince you that this is not the case: you admit that there are techniques hard to pull off in a statically typed language. To me, that's enough.
I'm afraid my stance remained the same: I consider any advantages of dynamic languages not worthy the disadvantages. For example, the technique of duck typing counts as one of the things I said I avoided in the hybrid language I use even though it can't do structural typing. What did change is my assumption that my stance is anywhere close to being scientifically proven.
>[My MUD with dynamically reloadable objects is] just an anecdote, but it's an example of a project where dynamic, dynamically typed language is a clear win over a static, statically typed one.
Yay, a use-case! Please provide some concrete examples. Since your case is pretty niche I hope we'll be able to generalize it to say, eg. "Reloading systems is bad, availability is good", and then contrast how what happens behind the scenes to facilitate that in a dynamic language differs from what happens when you use modules or services (other than ease of use, which is a valid argument itself). Thanks.
P.S. I realized I've mangled that medium. I really hope you won't insist I read the whole thing though. It sounds too subjective from what I've read.
I'd also like to address "big fonts": I grew up with UIs from the turn of the millenium and back then I thought professional software had to show a lot of things on the screen and have extensive menus. But I also noticed I could burn a CD much more easily using a free wizard-like version of the burning program than the paid full version. Thanks to mobile, at the price of shortening applications to apps, the world got easier, friendlier, cleaner UIs. While we previously thought that reducing the font size on our websites made them look cooler, now we saw that using big fonts we could make text look good while actually being radable.
So let us not go back to terminals maybe. Let us use the right (visual) tool for the right job.
>> Nowadays I see no notable arguments for dynamically typed programming languages. >A quick Google brought up an article from Dec 2016: https://medium.com/javascript-scene/you-might-not-need-types....
I glanced over it the other day and wasn't very interested. I wanted to give it a more thorough look before I replied to you, but it seems it got pulled. looks meaningfully
>What about Elixir and Clojure?
I see your Erlang dialect Elixir with Elm (arguably a dialect of ML). The Lisp Clojure is itself a bit older dialect of Lisp, so maybe Scala for that? I think Lisp and Erlang are mostly about the paradigm and concepts, not about being dynamic, what do you say? Talking about the JVM, I'll raise you a Kotlin. Also noteworthy is that Groovy got static type checking with v2. As for the CLR, I must say I don't know that much have changed since F# (a dialect of ML). Basically, you've had a nice pair of cards, but they make your hand. What I'm trying to reiterate is that there seems to be a definite trend towards types.
>Turing-complete[ness]
:/
>Racket contracts [...] providing the safety guarantees in [dynamic and static] worlds.
You didn't explain what they were, so I'll assume they're runtime guards. That means they're as useful as explicit runtime checks, but don't provide safety a static type checker would provide.
> Dialyzer is a static type checker, which only rejects programs it knows for sure will result in error. Traditional type systems require the programmer to supply the proof that the code is correct and will refuse to type check without one.
So weak (algebraic data) type inference? That's better than no checking. Now as far as weak vs strong typing goes, I'll agree to disagree about type coercion here. My default is maximum safety, but I won't claim that there are absolutely no domains where explicit conversions are a "pain" without much advantage. The suspicion that there might be some was the reason for my original challenge. I really wish someone would think that through and try and convince me.
>I mentioned Forth and Assembly because these are the only languages I know of (TCL may also qualify) which are truly unityped. I suppose you'd like dynamic typing more after working with something which lacks any kind of types.
I've worked with multiple assembly languages. An assembly programmer might use your "correct programs" argument and say: "Run-time checks are a pain; I don't want to check if quacking is an option, I know something clever will happen if you just jump; don't crash my program, it's correct!". I think this a valid argument only if the check overhead is prohibitively great. But what's prohibitive about compile-time checking? Time before you can run? You can reduce that with, say, incremental compilation. Don't allow certain bug types(pun) to go unnoticed and crash your program instead. It may not be as bad as what assembly would do, but it's still catastrophic.
>the most accurate auto-complete you've ever seen: at any point, you know exactly which classes have which methods.
I have that even when the program's not running :P
>Well, in any case, you shouldn't wait to "get convinced" by someone. You should try to learn the dynamic typing side of things on your own and use it for a while. It will make you a better programmer overall, even if you get back to static typing later.
I don't know why you assume my ignorance. I've used dynamically typed languages, I've studied the concepts, it's even possible I've seen the very Smalltalk talk you were thinking about before. I choose to avoid the dynamic capabilities of my otherwise statically typed language that I use at work. I'm still open to the possibility that there's gold buried somewhere, but I am not going dig just because you imply there is. People claim a lot of things are revolutionary which aren't. Give me an example why you say something's good, convince me it's worth my time. I do the same.
My invitation to provide arguments, or a domain for dynamic languages still stands.
EDIT: (Do not read this if you are kilbertp) Shh, I'm actually watching a video on the Dialyzer now
I probably shouldn't have used the word bubble, sorry. See my response to klibertp for hopefully some justification.
I have only used a JS live environment (the browser console) but I hope you have in mind something that my static language's debugger cannot do. I assume the next two languages are about reflection - I've done some. Finally, I'm unfamiliar with the Erlang's static analysis tool and I don't know Racket's contracts, but I'd like you to tell me how they differ and why you think they're better than my own.