3 ms·

"I really don't understand why." Because you are suffering from the exponential growth mindset, in which the next new thing is as important as the sum total of

by rsj_hn 10y ago

"I really don't understand why." Because you are suffering from the exponential growth mindset, in which the next new thing is as important as the sum total of all things that came before it. In that mindset, the future is emphasized and the past is heavily discounted. http://idlewords.com/talks/web_design_first_100_years.htm http://idlewords.com/talks/web_design_first_100_years.htm But that mindset is not shared by most firms in most industries, it's a unique pathology to the web. Businesses don't re-write working code just because a newer language version is available. Landlords don't tear down old apartment buildings just because more efficient building technologies are available. We live in a world in which COBOL runs a lot of mission critical code. Anything that touches important code that is now working is a risk and an expense, and what is the tangible gain for undertaking this expense? What new features will be added? How much more revenue will you get? What is the opportunity cost of having your engineers do that than something else, like adding a feature or improving test coverage? Before you say that it's simple, be aware that you are talking about messing with libraries that may not be maintained anymore. You are going to spend a lot of time debugging those old libraries as well as writing unit tests for them. Nothing in the world of software engineering is simple, especially when it comes to maintaining a large body of scripts. Imagine if in the Java world, it was announced that the Java 8 runtime would not support running Java 6 or older jars. How many jars are businesses running that were written in 2005? No one even know who wrote those libraries. Suppose in the C world, it was announced that code written in C'99 and before would no longer compile. The Linux kernel has code written in the 90s, and GCC has code written in the 70s and it's still supposed to compile under the most modern compiler. Moreover automated code re-writing tools don't come with guarantees of soundness or accuracy. There will be breakage, it will occur in random places, and there is zero upside to spending a lot of money to get an existing project to the same level of functionality as it had before you started messing with it. People who work in other languages get this. It's really not a difficult concept. Everyone other than the Python community agrees that Python did a massive screw up with python 3, just as the Perl community committed suicide by making Perl 6 not be compatible with Perl 5. I don't pretend to know what will be the future of Python -- maybe there isn't enough enterprise users out there to make a difference for the direction of the language -- but you do need to understand why breaking existing code is a deal breaker for the majority of business customers. You may disagree, but at least don't pretend that there is some irrational mysterious resistance to converting python2 code to python3.

raiph 10y ago
> making Perl 6 not be compatible with Perl 5. Imo that's either inaccurate or misleading. In Perl 6, `use` followed by a module name followed by a `:from` adverb leads Perl 6 to load the module, initialize it, and import its public functions, constants, variables, etc., AUTOMATICALLY BINDING THEM TO PERL 6, for any given supported other language the module is written in, provided someone has installed a suitable loader/binder (and the user has installed that plus the other language's interpreter, and the other language's module(s) that they wish to use). I'll start with a toy example. With a suitable "Perl 5" loader/binder in place, one could write the following and it would work as expected provided the user had installed the loader/binder, a compatible Perl 5 interpreter, and the Business::ISBN module (from https://metacpan.org/pod/Business::ISBN https://metacpan.org/pod/Business::ISBN): use Business::ISBN:from<Perl5>; my $isbn = Business::ISBN.new( '9781491954324' ); say $isbn.as_isbn10.as_string; Stefan Seifert has written just such a Perl 5 loader/binder and steadily improved it over the last few years to the point it's a serious solution. With Stefan's loader/binder, not only do toy examples like the above work, so do non-toy examples like writing controllers for the Catalyst MVC web framework even though Catalyst is large and complex, written in Perl 5 with XS (C lib) extensions, written without regard to Perl 6, and even though a controller has to be a subclass of a Perl 5 class provided by Catalyst.
- chromatic 10y ago
  This argument is disingenuous. The same feature is available in any language with a decent FFI (must support loading an arbitrary shared library, marshalling/demarshalling data between languages, and invoking functions in the shared library). This is possible in Python, Ruby, Java, Racket, Rust, Perl, Go, and plenty of other languages I'm forgetting or haven't used. Yet who would seriously argue that "Python is compatible with Perl" because you can embed libperl in a Python program? You might as well argue that "Rakudo is compatible with libssl", for all the relationship Rakudo source code has with Perl source code.

by rsj_hn 10y ago

raiph 10y ago

> making Perl 6 not be compatible with Perl 5. Imo that's either inaccurate or misleading. In Perl 6, `use` followed by a module name followed by a `:from` adverb leads Perl 6 to load the module, initialize it, and import its public functions, constants, variables, etc., AUTOMATICALLY BINDING THEM TO PERL 6, for any given supported other language the module is written in, provided someone has installed a suitable loader/binder (and the user has installed that plus the other language's interpreter, and the other language's module(s) that they wish to use). I'll start with a toy example. With a suitable "Perl 5" loader/binder in place, one could write the following and it would work as expected provided the user had installed the loader/binder, a compatible Perl 5 interpreter, and the Business::ISBN module (from https://metacpan.org/pod/Business::ISBN https://metacpan.org/pod/Business::ISBN): use Business::ISBN:from<Perl5>; my $isbn = Business::ISBN.new( '9781491954324' ); say $isbn.as_isbn10.as_string; Stefan Seifert has written just such a Perl 5 loader/binder and steadily improved it over the last few years to the point it's a serious solution. With Stefan's loader/binder, not only do toy examples like the above work, so do non-toy examples like writing controllers for the Catalyst MVC web framework even though Catalyst is large and complex, written in Perl 5 with XS (C lib) extensions, written without regard to Perl 6, and even though a controller has to be a subclass of a Perl 5 class provided by Catalyst.

chromatic 10y ago
This argument is disingenuous. The same feature is available in any language with a decent FFI (must support loading an arbitrary shared library, marshalling/demarshalling data between languages, and invoking functions in the shared library). This is possible in Python, Ruby, Java, Racket, Rust, Perl, Go, and plenty of other languages I'm forgetting or haven't used. Yet who would seriously argue that "Python is compatible with Perl" because you can embed libperl in a Python program? You might as well argue that "Rakudo is compatible with libssl", for all the relationship Rakudo source code has with Perl source code.