4 ms·

I’d argue that learning the syntax is not the same as learning the language, which is utterly impossible to do in a few days. Right now I’m dabbling with Go, a

I’d argue that learning the syntax is not the same as learning the language, which is utterly impossible to do in a few days. Right now I’m dabbling with Go, and trying to figure out whether or not I should use a Context to propagate my log instance. These are design choices, trade-offs, that you can only fully make once you’re properly familiar with the language’s idiomatic approach to solving problems. Otherwise you’re just shipping poor quality code.

xxs 5y ago
>which is utterly impossible to do in a few days Totally disagree. The main principles are quite the same - most of the stuff is either a datastructure (that you already know how it works/performs/complexity) or it translates to an OS call. Now, there are frameworks with their own caveats. In the end all languages must end up in machine code one way or another. There are not many ways to make the latter work in an efficient manner, so you get a pretty decent expectation what it should be happening. On top of that most of the frameworks and languages do have source code that can be checked too. Logging in most languages is per class/namespace/package and tends to be a static one (static in Java/C#/C version).
- stingraycharles 5y ago
  You’re focusing on the low level when you’re saying that everything ends up in the same system call. I’m talking about the way you solve problems, picking the right abstractions, and using the correct idioms. If you’re claiming someone is perfectly able to learn all this in a few days of time, then what makes the difference between that person and someone with a few months of experience? What about a year or two?
  - xxs 5y ago
    >If you’re claiming someone is perfectly able to learn all this in a few days of time About being perfect - I'd not claim that even after many years of experience, yet to do a decent job a week is more or less enough. Productivity might suffer, if changing the IDE/toolchain drastically, but that's a learning process and nothing hard either.
- ihateolives 5y ago
  > Totally disagree. The main principles are quite the same ... but not the ways to write them. Idiomatic use is a thing. You see this all the time, people come from Java and try to write Kotlin/Go as if it were Java and that results in a code thats hard to understand and inefficient.
  - Fire-Dragon-DoL 5y ago
    Any decent book exposes the developer to idioms while teaching the syntax, though.
Fire-Dragon-DoL 5y ago
My point plays on purpose on the ambiguity of the title, it's not specified what it means with language. As for syntax, I highly disagree too, it takes me a few days to get that at most nowadays. Idioms, it takes longer (weeks), but knowing what to search makes a big difference in time. As for log, you shouldn't, assuming the reason for passing it around is testing. Go and Elixir use a similar idiom in that case where mocks aren't used, so in the case of a log library, the direct dependency with an option to disable logging in tests is preferable

xxs 5y ago

>which is utterly impossible to do in a few days Totally disagree. The main principles are quite the same - most of the stuff is either a datastructure (that you already know how it works/performs/complexity) or it translates to an OS call. Now, there are frameworks with their own caveats. In the end all languages must end up in machine code one way or another. There are not many ways to make the latter work in an efficient manner, so you get a pretty decent expectation what it should be happening. On top of that most of the frameworks and languages do have source code that can be checked too. Logging in most languages is per class/namespace/package and tends to be a static one (static in Java/C#/C version).

stingraycharles 5y ago
You’re focusing on the low level when you’re saying that everything ends up in the same system call. I’m talking about the way you solve problems, picking the right abstractions, and using the correct idioms. If you’re claiming someone is perfectly able to learn all this in a few days of time, then what makes the difference between that person and someone with a few months of experience? What about a year or two?
- xxs 5y ago
  >If you’re claiming someone is perfectly able to learn all this in a few days of time About being perfect - I'd not claim that even after many years of experience, yet to do a decent job a week is more or less enough. Productivity might suffer, if changing the IDE/toolchain drastically, but that's a learning process and nothing hard either.
ihateolives 5y ago
> Totally disagree. The main principles are quite the same ... but not the ways to write them. Idiomatic use is a thing. You see this all the time, people come from Java and try to write Kotlin/Go as if it were Java and that results in a code thats hard to understand and inefficient.
- Fire-Dragon-DoL 5y ago
  Any decent book exposes the developer to idioms while teaching the syntax, though.

Fire-Dragon-DoL 5y ago

My point plays on purpose on the ambiguity of the title, it's not specified what it means with language. As for syntax, I highly disagree too, it takes me a few days to get that at most nowadays. Idioms, it takes longer (weeks), but knowing what to search makes a big difference in time. As for log, you shouldn't, assuming the reason for passing it around is testing. Go and Elixir use a similar idiom in that case where mocks aren't used, so in the case of a log library, the direct dependency with an option to disable logging in tests is preferable