Comment by belorn | Hacker News Reader

Comment by belorn | Hacker News Reader

Parent Full thread

Here is a real life example. I have a library that communicate with an API that extract information, and now I want it to also grab an additional field and extract it to a database. The goal is to figure out which functions in the code accesses the field, where the best spot is to extract the information, and what the best way to call into the database without adding too much code in places where it shouldn't be. In addition I need to keep the information synced over time.

Do I care what the different functions in the library return? No. The field could exist in everything from an XML object, a dict, a string, a byte array, or a custom object made for easy interaction. What I need to know is where in the flow I can best inject my new code, and in order to do so I need to know when and where the information can be accessed. In an optimal world I would have written a shell script, and in that case every function has a single return type which is string.

I can't answer your question. You may care since you may not want to break other code within the library that depends on what is returned by the function (depends how it looks like).

Otherwise I don't know why you would particularly care more about types with st than otherwise You'd just follow the same pattern as you did when extracting the other fields. E.g. if the fields to extract are listed in a list like structure, you're just going to add the extra field to the list. And in case of static typing, you'll get soonish feedback if you messed something up.

The return type thing was just an example to show that you care about return types regardless of static typing, not that you care about return types during every act of programming.

> The return type thing was just an example to show that you care about return types regardless of static typing, not that you care about return types during every act of programming.

If we both agree that you do not need to care about types during every act of programming, then lets follow that thread and see where it leads. When do you need to care about types, and how big portion of a programmers time is spent on thinking about types?

My own expensive provides the answer "rarely" and "as little as possible". The few times I do care about types is when interacting with third-party functions, and in those cases I read the manual to figure out what their functions are returning and what I can expect to use. I do not however write test that verify that a function that is documented to return a string actually do return a string (or expect my compiler to do it for me). If the documentation is incorrect then I treat that as a bug, just as if it was a logic bug.

It would however be interesting to hear how much others spend time on it, and in what kind of acts of programming.

This. I was wondering if it's because I'm a web dev that I rarely care/think/debug typing issues or what. I hear the stories I'm just not sure what everyone is talking about. I did have that in js a bit (the good old == vs ===) but not with Ruby.

I think about types (almost?) every time I write a function. What type of data does the function expect, and what type of data am I supposed to transform this data to?

For instance, if I calculate the time that has elapsed between two points in time: - what does my input look like (e.g. two objects that look like XY) - in what form should I return the difference? Time in seconds (i.e. number), again an object that looks like XY ? ...

I can't imagine saying I would care about types rarely.

Another nice benefit of st langs is that you have to read manuals less often. IDEs so a way better job showing you the type of every variable (and result of an operation) as well as the options you have at your hand for a given type (including their documentation and example code). Yes I know dt languages and their tools try to catch up.

> or expect my compiler to do it for me). If the documentation is incorrect then I treat that as a bug, just as if it was a logic bug.

Well, I don't expect that with Dr languages as well, but I am glad that the compiler does this (or in DT languages at least the IDE due to type hints). I mean, it saves a lot of time (money) later on ... even if you notice it right away the first time you use the code

Interesting, let me do the same example and see how my thought process differ.

I would first ask, should I write a function or maybe have this as an property of the object that has the original data. I want the intended interface to influence my design.

What methods does my input has? Does it already implement what I want or have a helper function that makes writing the transformation easier? Is there built in functions or third-party libraries that do time differences calculations.

Within python I would apply some minor assumptions about types. If something is a time it is either a string or an object with a time interface, and so I might need to cast it to a time-like object. Preferable this already occurred as close to the edge of the program as possible so in the rest of the program I don't need to put any thought about the type. If its a date, it should be a an object with a time interface. If time strings are floating around in the data flow, just as with byte strings, I should try to fix that as early and close to the edge of the program.

There seems to be a similar view about unicode. You don't want to have every function check if the input is of the type unicode. Instead what people do is when they read a byte string, they turn it into unicode as everything else assume the unicode interface.

Thanks for confirming

If you do not care about the type, and indeed do not do anything special with it other than pass it through to somewhere (that may or may not care about it), then there are types that let you do that.

A good typed language will allow you to be more or less strict about what you accept (eg. a specific literal string, a set of strings, any string, any string like object, any object...)

If there are types that allow you to not care about the type, then why have a type?

People argue that they need types to very that you do not add in programming errors, and in order to easier read what the code does. In the environment I operate in and the jobs I do, types do not achieve those things. All they do is add unnecessary information and restrictions that need to be worked around.

Shell is an interesting environment in that there really is only one type: string. There are no int, no floats, barely any arrays (rare enough that I don't ever use them). You run a program with string inputs and you may get an string output in return. The majority time writing a shell script is spent on manuals, understanding how different programs interact, and data flows. This remain mostly true for dynamic languages. For static typed languages some of the time get redirected on dealing with types, declaring types ahead, and making sure the type declarations and castings are correct.

You're making an entire argument about something you clearly haven't properly tried. It sounds like you have your own misconceptions about what static typing is and how types work. Your premise is flawed so it's difficult to have a conversation.

I would encourage you to try typescript for a while, it's very approachable and has excellent tooling.

One can measure the quality of a discussion in how often people refer to the arguments, and how often they refer to the person. You're making... you have your own misconceptions... Your premise is flawed... encourage you to try...

I have worked with 10+ different languages, multiple different IDE's, some types and some dynamic, some like shell which doesn't really have the concept of types at all.

If you are encouraging me to try typescript because you think its great, then I would encourage you in return to test python in combination with system and integration tests. It makes for a very safe environment where you know your code is working.

I've worked with python for 17 years. I maintain that given your arguments, you haven't tried a properly set up static language.

I know how to make python safe with TDD. It doesn't even sort of compare.

You can maintain that if you like.

I don't want to speculate why you feel so attached to static languages. I worked with python in 15 years, you in 17. I have done low level embedded C code. I done web development, and shell scripts. Tried lisp, and programmed in Ada. If you have also worked with similar amount of languages and reach a different conclusion then either your work is very different from mine, or you as an other person have a different experience than mine.

When it comes to keeping simple thing being simple, static languages has never delivered for me. In embedded system I live with that aspect, but that's the nature of such environments. The primary question when working with dynamic language is: "is there already a library that does what I want, and how do I modify it to work in my use case". Instead of thinking about structure and types, I am thinking about interfaces.

I will conceit one example where a static typed language is much better than a dynamic typed, and it illustrate the environment where such language aspect shine. SQL. SQL with dynamic types would be horrible and any database which treat types some-what dynamic is a horror to work with. SQL does not make simple things simple, and database exceptions are quite harsh in every aspect. There is also few if any interfaces, so its types or nothing.

    If there are types that allow you to not care about the type, then why have a type?

The type represents a set of properties about the inhabiting values so if you have an opaque value you don't want others to inspect, wrapping it in such a type makes that explicit throughout the rest of the program. That information is not available if every value in your type has the same type. Presumably though you will actually attempt to do something with the contained value at some point so you must have some expectation about what it is.

Reply on news.ycombinator.com