3 ms·

I'm not trying to be pedantic. Please do not assume bad faith. I'm just trying to understand that worldview, which just seems drastically different from mine,

by q3k 6y ago

I'm not trying to be pedantic. Please do not assume bad faith. I'm just trying to understand that worldview, which just seems drastically different from mine, even though we both seem to be generalists. If there is something that Go, or any other product, could do better to be better suited to your workflow, I would like to know what it is. I don't write Perl, but if I had to qualify some piece of software that used it at work, I would make time then to learn as much of the basics of it that is needed to more easily get by. Even if it meant a day of reading Perl/CPAN docs to do 15 minutes of actual 'work', especially if the alternative is one or two days of blindly stumbling around to then not even be exactly sure if my 'yes/no' answer was correct. I don't even see much of a difference between learning something and just working with it - I can't imagine not having a browser window open with the docs/source code/whatever of what I'm currently working with. In that way I've learned a fair bit of technologies I would have never touched otherwise, but now their knowledge, even at a surface level, is worth more than the sum of the products.

doublerabbit 6y ago
I mean no offense and sorry for my angst if it came that way. It's frustrating when I can't paint my view and then get battled to death because of it. TCL. TCL is the only language workflow that has worked for without any stress. proc SomeProcedure {variable} { Code it to do something for yourself } save, run and it works. No need to include modules, no need to download anything. I use my own TK/Gui interface which does stuff for me to make my life easier. And if I handed it to you, it would be in one folder with all files present no dependencies required. However I understand life is not like that unfortunately. > I can't imagine not having a browser window open with the docs/source code/whatever of what I'm currently working with. I don't. If at any point I need source code, I'll download it locally and compile/run it first. Then edit it learn the logic and flow of the program. I'm in terminal 99% of the time, orchestrating systems ranging from FreeBSD to Linux and AIX, if a browser is open it's for Slack, emails. I am someone who wants to type "man something" and get a man page of it. vim Library/file.pm and be able to view the code under the hood for that specific project. That's simplicity and that's how it should be -- The over-hassle of downloading from git, forking it, apply push,pull changes just isn't my street specially assuming my box I'm working with has internet.
- hnlmorg 6y ago
  The issue is you presented opinion as fact. Opinion: I don't enjoy Go as much as Perl. [PASS] Opinion: I'm more comfortable with Perl because I've spent more time in it. [PASS] Both are perfectly acceptable. However you made comments about objective truths that were incorrect: Truth: Go doesn't download modules to disk. [FAIL] For what it's worth, I really like Perl too. Us two are a dying breed in that regard. I was in two minds whether to reply because of that respect I have for fellow Perl hackers. But you kept repeating the same falsehoods as fact :( Take your latest comment for example, you can bring up the Go docs for packages in the terminal as well: go doc $PACKAGE So even there your Perl point is still equivalent to Go on an objective level. But I don't blame you for not liking/enjoying a language on a personal level.
  - doublerabbit 6y ago
    My original discussion was of that I thought Go was very hidden under the hood. I gave an example and got mobbed for it. I replied with emotion and misunderstanding and here we are. The main thing I was going on is "Here's a GitHub link, add it to your code and you have an instant logger thing". Magic in my eyes and this blinding light throws me off. Unlike Perl where the code is in a .pm file in front of you. That was what I was trying portray. I'm going to leave this discussion to rest as it's all went wrong anyway. Tomorrow will be tomorrow and this will all be forgotten in a day. Thank you for your responses and have a good evening.
    - hnlmorg 6y ago
      But the point is Go and Perl behave exactly the same way with regards to all the points you argued where they differ. Literally every point you've raised people have proven false. The problem here isn't that Go has some hidden magic, it's that you've never bothered to spend even 10 seconds checking if the packages were downloaded; instead inventing some wild, made up, theories about how things might work. This lead you to make some pretty daft claims like the Go compiler can build code that doesn't exist on disk (even as a non-developer sysadmin you must realise that's a pretty stupid claim to make?) To be honest, I wonder if you're even using Perl correctly because if you're installing CPAN modules correctly then the .pm file is stashed away in an alternative directory that's looked up via an environmental variable -- just like with Go. The Perl module shouldn't be present in your projects workspace (and actually Go makes things easier than Perl here by allowing modules to be "vendored"). Go and Perl are very similar in a great many ways: + Both languages order modules/packages by directory hierarchies + Both languages look up module/package paths via special environmental variables + Both have CLI tooling to download and install modules/packages + Both have CLI tooling to read module/package documentation + Both are very much command line orientated + Both are imperative languages who's object systems feel like a half-arsed after thought and thus both really feel more at home writing functional code than OOP. + Both allow functions to return multiple parameters (a trait that's not too common outside of Perl and Go) + Both are strictly typed, support duck typing, and have a fairly limited type system. + Both treat arrays/slices and hash/maps as special types where the runtime has to have special code for handling them (ie you couldn't create a custom data type like a array/slice nor hash/map using Perl/Go's own standard library). In fact the very reason I warmed to Go was because it felt like a nice hybrid between Perl and C. This was why I was so baffled when you said Go had some hidden behaviours under the hood when in fact managing a Go project is actually very similar to managing a Perl project.

by q3k 6y ago

doublerabbit 6y ago

I mean no offense and sorry for my angst if it came that way. It's frustrating when I can't paint my view and then get battled to death because of it. TCL. TCL is the only language workflow that has worked for without any stress. proc SomeProcedure {variable} { Code it to do something for yourself } save, run and it works. No need to include modules, no need to download anything. I use my own TK/Gui interface which does stuff for me to make my life easier. And if I handed it to you, it would be in one folder with all files present no dependencies required. However I understand life is not like that unfortunately. > I can't imagine not having a browser window open with the docs/source code/whatever of what I'm currently working with. I don't. If at any point I need source code, I'll download it locally and compile/run it first. Then edit it learn the logic and flow of the program. I'm in terminal 99% of the time, orchestrating systems ranging from FreeBSD to Linux and AIX, if a browser is open it's for Slack, emails. I am someone who wants to type "man something" and get a man page of it. vim Library/file.pm and be able to view the code under the hood for that specific project. That's simplicity and that's how it should be -- The over-hassle of downloading from git, forking it, apply push,pull changes just isn't my street specially assuming my box I'm working with has internet.

hnlmorg 6y ago
The issue is you presented opinion as fact. Opinion: I don't enjoy Go as much as Perl. [PASS] Opinion: I'm more comfortable with Perl because I've spent more time in it. [PASS] Both are perfectly acceptable. However you made comments about objective truths that were incorrect: Truth: Go doesn't download modules to disk. [FAIL] For what it's worth, I really like Perl too. Us two are a dying breed in that regard. I was in two minds whether to reply because of that respect I have for fellow Perl hackers. But you kept repeating the same falsehoods as fact :( Take your latest comment for example, you can bring up the Go docs for packages in the terminal as well: go doc $PACKAGE So even there your Perl point is still equivalent to Go on an objective level. But I don't blame you for not liking/enjoying a language on a personal level.
- doublerabbit 6y ago
  My original discussion was of that I thought Go was very hidden under the hood. I gave an example and got mobbed for it. I replied with emotion and misunderstanding and here we are. The main thing I was going on is "Here's a GitHub link, add it to your code and you have an instant logger thing". Magic in my eyes and this blinding light throws me off. Unlike Perl where the code is in a .pm file in front of you. That was what I was trying portray. I'm going to leave this discussion to rest as it's all went wrong anyway. Tomorrow will be tomorrow and this will all be forgotten in a day. Thank you for your responses and have a good evening.
  - hnlmorg 6y ago
    But the point is Go and Perl behave exactly the same way with regards to all the points you argued where they differ. Literally every point you've raised people have proven false. The problem here isn't that Go has some hidden magic, it's that you've never bothered to spend even 10 seconds checking if the packages were downloaded; instead inventing some wild, made up, theories about how things might work. This lead you to make some pretty daft claims like the Go compiler can build code that doesn't exist on disk (even as a non-developer sysadmin you must realise that's a pretty stupid claim to make?) To be honest, I wonder if you're even using Perl correctly because if you're installing CPAN modules correctly then the .pm file is stashed away in an alternative directory that's looked up via an environmental variable -- just like with Go. The Perl module shouldn't be present in your projects workspace (and actually Go makes things easier than Perl here by allowing modules to be "vendored"). Go and Perl are very similar in a great many ways: + Both languages order modules/packages by directory hierarchies + Both languages look up module/package paths via special environmental variables + Both have CLI tooling to download and install modules/packages + Both have CLI tooling to read module/package documentation + Both are very much command line orientated + Both are imperative languages who's object systems feel like a half-arsed after thought and thus both really feel more at home writing functional code than OOP. + Both allow functions to return multiple parameters (a trait that's not too common outside of Perl and Go) + Both are strictly typed, support duck typing, and have a fairly limited type system. + Both treat arrays/slices and hash/maps as special types where the runtime has to have special code for handling them (ie you couldn't create a custom data type like a array/slice nor hash/map using Perl/Go's own standard library). In fact the very reason I warmed to Go was because it felt like a nice hybrid between Perl and C. This was why I was so baffled when you said Go had some hidden behaviours under the hood when in fact managing a Go project is actually very similar to managing a Perl project.