101–110 of 141 posts
Earlier quoted context omitted.
JavaScript is functional and oh boy!
Yes, but Javascript developers aren't functional. In either sense of the word.
Earlier quoted context omitted.
Python IS strongly typed. ie: 1 == '1' is FALSE, and 2 + '2' raises an exception.
So forgive jompe for using the wrong term. The point, however, was clear. It wasn't "strong vs weak"; the point clearly was "compile time vs run time". And, well, Python is, from jompe's perspective, on the wrong side of the line, no matter how "strong" Python's type system is.
A Redux reducer consuming an Action object would possess the same properties, no?
Earlier quoted context omitted.
Python IS strongly typed. ie: 1 == '1' is FALSE, and 2 + '2' raises an exception.
So forgive jompe for using the wrong term. The point, however, was clear. It wasn't "strong vs weak"; the point clearly was "compile time vs run time". And, well, Python is, from jompe's perspective, on the wrong side of the line, no matter how "strong" Python's type system is.
Whether or not a specific method of typing is good or bad depends on the project and the developer(s) working on it. But if you're going to use that as a reason to make decisions, then you should understand the difference.
>> Extreme late-binding is important because Kay argues that it permits you to not commit too early to the "one true way" of solving an issue (and thus makes it easier to change those decisions), but can also allow you to build systems that you can change while they are still running! >> Binding can also refer to binding a variable type to data. As someone who has over 15 years of experience going back and forth betw…
I really don't agree with your point. The analogy Kay uses with biology is very telling : Cells (co-)evolved for billions of years, they were not "designed" to accomplish certain tasks. Just survival and reproduction. And still, even with those billion of years, we still have cancer (as in bug in the reproduction process). We design software. We evolve software. Software doesn't build itself, or decide for itself wha…
I think that's a misleading summary. Both dynamic and static languages suffer when it comes to changes over time (people will argue over which suffers more, but both suffer) so solving problems you haven't thought through is hardly a problem unique to dynamic languages.
Earlier quoted context omitted.
> https://vimeo.com/9270320 There's very little you can prove, other than "less code gives you fewer errors/bugs". Arguably, this is primarily due to specification gaps being opaque and less logic to hold state. You can't file a bug or raise an issue about a choice that was already made by a dynamic language. > It's only a shame if you presume to know better than all of those developers. Statistically, someone is goi…
> Statistically, someone is going to be right. Yes. If you ask 100 people what the answer to "3 + 5" is, you'll mostly get "8". But that's because you're asking them all for the right answer to the same problem. If you ask 80 of them the answer to "3 + 5" and 20 the answer to "3 + 2", the right answer isn't 8 and the people who answered 5 for the latter aren't wrong. They are solving different problems. Given the bre…
I never liked the "pick the right tool for job" cliche in the context of programming languages. I'm curious if you can imagine a single programming language which you /would/ prefer for all of the different kinds of programs you've written. Not that it does exist, but could it?
Other than size, weight, power, and price limitations, I don't pick different computers for different problems. I mean I could live with one ISA for pretty much everything, including GPUs. I'm sure different people would pick different answers (one of your points), but after looking at a lot of languages over the years (including some of yours), I can't come up with two features I want which are inherently in conflict and necessitate being different languages.
I don't think it has to be a superset of all languages monstrosity either. And for the sake of argument, let's say this is just for one-person development. There's too much politics in trying to decide what features you /don't/ want your coworkers to abuse. :-)
Earlier quoted context omitted.
> Statistically, someone is going to be right. Yes. If you ask 100 people what the answer to "3 + 5" is, you'll mostly get "8". But that's because you're asking them all for the right answer to the same problem. If you ask 80 of them the answer to "3 + 5" and 20 the answer to "3 + 2", the right answer isn't 8 and the people who answered 5 for the latter aren't wrong. They are solving different problems. Given the bre…
> I can't point to a single language that I would prefer for all of the different kinds of programs I've written. I never liked the "pick the right tool for job" cliche in the context of programming languages. I'm curious if you can imagine a single programming language which you /would/ prefer for all of the different kinds of programs you've written. Not that it does exist, but could it? Other than size, weight, po…
Nope. Granted, I may work on a greater breadth of software than the average programmer. But, at the very least, I have implemented language VMs and garbage collectors where I needed to work at the level of raw bytes and manual memory management. But I sure as hell prefer memory safe languages when I'm not doing that.
I like static types for decent-sized programs, but I also use config files and other "data languages" where that would be more frustrating than anything.
Even if there was a single language that was perfect for me for all of the code I write, I don't expect that that language would be perfect for others, and I don't think those people are wrong.
Earlier quoted context omitted.
I'm a fresh graduate from uni so I'd say that I don't have that much experience. My last years working on the side of studies using Python really made me prefer strongly typed languages like Haskell, Rust, Elm etc. My experience is that the compiler almost always finds my small errors and would-be-bugs which Python exposes at runtime (crashes with e.g. None-type errors). What would you say the benefits are with dynam…
I don't have any particular love for dynamic typing, but I really can't find a language I like developing in more than Python. I use type hints wherever I can so I (and others) know what the hell is going on, but I have yet to find a language as expressive and productive with so many great stdlib or community packages as Python. I started futzing with Golang but I felt like I was always typing 50 lines to do what I c…
Earlier quoted context omitted.
I really don't agree with your point. The analogy Kay uses with biology is very telling : Cells (co-)evolved for billions of years, they were not "designed" to accomplish certain tasks. Just survival and reproduction. And still, even with those billion of years, we still have cancer (as in bug in the reproduction process). We design software. We evolve software. Software doesn't build itself, or decide for itself wha…
> Dynamic languages let you think a problem you haven't thought of at design time will somehow solve itself magically at runtime, using components designed weeks before, with knowledge of that time. I don't think most people who program in dynamically typed languages believe that. However there are people in the extreme that believe that static typing will save you from errors. Sometimes I worry that the cognitive ov…
Many real-world entities don't have a fixed set of characteristics/properties; instead, they have fluid characteristics that can change over time.
Trying to model those entities using static types which have a fixed/static set of properties is a bad idea.
For example, in nature, a tadpole might grow arms and legs and become a frog. Trying to represent a single entity using two different classes 'Tadpole' and 'Frog' doesn't always work... What type is the creature if it's exactly halfway between being a Tadpole and a Frog? Do you keep inventing new discrete types to keep re-categorizing the creature as it grows or do you acknowledge that the exact type of this creature cannot be expressed discretely but that it lies on a continuum?
Earlier quoted context omitted.
> I have a ton of respect for Alan Kay and think he's a genius. But why does it seem like every time he talks about OO it's always painting an apocalyptic picture like we're in some kind of twilight zone alternate nightmare reality of broken patterns and models? Because we are? Have you seen most OOP code-bases, they are a train wreck!
Could you elaborate on the “most” part? Coming from my experience on Rails over the past couple of years, I’m quite happy with what I’ve found so far.