2 ms·

I don't want to call someone I don't know a bad developer, but as a general rule if software is moving more towards safety and reliability and you are resisting

by ebbv 10y ago

I don't want to call someone I don't know a bad developer, but as a general rule if software is moving more towards safety and reliability and you are resisting that change that's a sign there's a problem with your habits and preferences. Not that the decisions being made are bad. Swift is not a perfect language, there's a lot of low hanging fruit (some of which is being dealt with in Swift 3), but it's lack of support for dynamic behavior is not one of those problems.

andybak 10y ago
> if software is moving more towards safety and reliability and you are resisting that change that's a sign there's a problem with your habits and preferences Unless safety and reliability come at the cost of some other metrics that you consider more valuable? Currently - at least in the HN bubble - it appears that the pendulum is swinging towards static typing and away from dynamic language features. It is surely premature to conclude this is a permanent trend.
mikeash 10y ago
People rarely if ever argue that they want to write less reliable software because it's easier. The typical argument is that type safety does not necessarily translate into programmer safety, and that the resulting programs are more safe and more reliable. I don't tend to agree with those arguments (at least for now, I reserve the right to change my mind again) but I don't think that it's useful to just dismiss them based on their basic shape.
phink 10y ago
Swift is not even safer than Objective C since you can pepper your code with ? and ! and get the same runtime problems. I would even say that it is less safe as time pressure and having to spend time on such trivial things combine to make you lazy about it and just add them to keep the compiler happy.
mamcx 10y ago
I love static typing and stronger type systems, but I'm also mainly a data dev guy (that do CRUDs and data manipulation, plus app/web development). The big trouble with inflexibles types is that work against data manipulation. Data using maybe not, but is a mile easier to do database development in python than in F#. My ideal setup is a strict-types first and dynamic optional, so I can do: row = MakeRow() row?first_name = "Jhon" row?last_name = "Doe" row?fullName = fun row:Row -> row?first_name + " " + row?last_name and stuff like that... But still keep the type system everywhere! fun sum(a, b:Int):Int -> a + b Mainly, because readability. I think that is better when you can stare at a fragment of code and extract as much info as posible. Type annotations help that. That infuriate me about F#. I do python, and in both basic code "look the same". But I hate that F# know the types of things but do not tell me! (without a IDE!) and I still need to track down the flow of code to figure out things. Type inference must be local, imho. Or not at all...

by ebbv 10y ago

andybak 10y ago

> if software is moving more towards safety and reliability and you are resisting that change that's a sign there's a problem with your habits and preferences Unless safety and reliability come at the cost of some other metrics that you consider more valuable? Currently - at least in the HN bubble - it appears that the pendulum is swinging towards static typing and away from dynamic language features. It is surely premature to conclude this is a permanent trend.

mikeash 10y ago

People rarely if ever argue that they want to write less reliable software because it's easier. The typical argument is that type safety does not necessarily translate into programmer safety, and that the resulting programs are more safe and more reliable. I don't tend to agree with those arguments (at least for now, I reserve the right to change my mind again) but I don't think that it's useful to just dismiss them based on their basic shape.

phink 10y ago

Swift is not even safer than Objective C since you can pepper your code with ? and ! and get the same runtime problems. I would even say that it is less safe as time pressure and having to spend time on such trivial things combine to make you lazy about it and just add them to keep the compiler happy.

mamcx 10y ago

I love static typing and stronger type systems, but I'm also mainly a data dev guy (that do CRUDs and data manipulation, plus app/web development). The big trouble with inflexibles types is that work against data manipulation. Data using maybe not, but is a mile easier to do database development in python than in F#. My ideal setup is a strict-types first and dynamic optional, so I can do: row = MakeRow() row?first_name = "Jhon" row?last_name = "Doe" row?fullName = fun row:Row -> row?first_name + " " + row?last_name and stuff like that... But still keep the type system everywhere! fun sum(a, b:Int):Int -> a + b Mainly, because readability. I think that is better when you can stare at a fragment of code and extract as much info as posible. Type annotations help that. That infuriate me about F#. I do python, and in both basic code "look the same". But I hate that F# know the types of things but do not tell me! (without a IDE!) and I still need to track down the flow of code to figure out things. Type inference must be local, imho. Or not at all...