3 ms·

> People have different styles and preferences. In terms of Haskell, it's not a question of style or preference, but provable correctness of the underlying the

> People have different styles and preferences. In terms of Haskell, it's not a question of style or preference, but provable correctness of the underlying theory. I don't think programmers should have to be category theorists to 'effectively wield' a language, but category theorists sure as shit ought to be involved in designing the language being wielded. I'm not a Haskeller, but I very much respect the research they've done, and continue to do -- and how it significantly improves the languages I do use. However, the design and culture of languages like JavaScript are very much mired in inconsistent misguided design and cultural anti-intellectualism; they do not and can not benefit from the advancement in the state of the art, and are the programming equivalent of building bridges and skyscrapers without consulting structural/material engineers, based on a back-of-the-napkin sketch. Personally, I don't prefer static typing -- I simply don't know of any other mechanism by which I can actually have a hope of understanding software I'm writing of any appreciable level of complexity. I don't see where "preference" fits in here, other than "preferring" to not actually fully understand the system you're building.

somebehemoth 13y ago
Bold claims and strong language do not make up for a lack of citations. You prefer static typing because you admit it is the only hope you have of understanding your complex code. However you dismiss other peoples' preferences by claiming they are ignorant of the systems they are building. Are you, perhaps, the one true Scotsman?
- teacup50 13y ago
  It's not possible for anyone to build complex software in a unityped language while having a full, complete, and verifiable understanding of their own system invariants at any given moment. Claims otherwise are the literal equivalent of making complex mathematical assertions without a single condensed proof. This isn't opinion, any more than a formal proof is opinion.
  - somebehemoth 13y ago
    You are making an opinion as to the definition of complex software. "Complex software" means different things to different people. Additionally, you've inserted a requirement of understanding one's systems that seems arbitrary and not universally applicable. Whatever happened to each his own?
    - teacup50 13y ago
      > You are making an opinion as to the definition of complex software. "Complex software" means different things to different people. "Complex" math or "complex" engineering means different things to different people, but "mathematical proof" and "deductive reasoning" do not. > Additionally, you've inserted a requirement of understanding one's systems that seems arbitrary and not universally applicable. It's not arbitrary, it's how we build systems that work, and work better. http://en.wikipedia.org/wiki/Engineering#Methodology http://en.wikipedia.org/wiki/Engineering#Methodology "By understanding the constraints, engineers derive specifications for the limits within which a viable object or system may be produced and operated." Without understanding one's system, it is impossible to understand its relation to one's constraints, and it is impossible to define the specifications within which that system operates. It's possible to build a car or an engine without understanding the math and science behind them, but it's impossible to build an engine of known specifications, it's impossible to provably assert that it operates within those specifications, and it's impossible to engage in directed design based on those specifications and defined operational limits. The best you can hope for is purely empirical evidence, and empirical evidence is of limited utility without a theoretical framework in which it can be applied to extrapolate further knowledge. As a result, systems designed and implemented without concern for understanding the theoretical basis of their operation invariably perform more poorly and cannot compete with systems designed and implemented based on building and applying a theoretically driven specification and understanding of constraints. To willfully prefer ignorance is objectively worse. > Whatever happened to each his own? Applied maths. It's either correct and verifiable or it's not.

somebehemoth 13y ago

Bold claims and strong language do not make up for a lack of citations. You prefer static typing because you admit it is the only hope you have of understanding your complex code. However you dismiss other peoples' preferences by claiming they are ignorant of the systems they are building. Are you, perhaps, the one true Scotsman?

teacup50 13y ago
It's not possible for anyone to build complex software in a unityped language while having a full, complete, and verifiable understanding of their own system invariants at any given moment. Claims otherwise are the literal equivalent of making complex mathematical assertions without a single condensed proof. This isn't opinion, any more than a formal proof is opinion.
- somebehemoth 13y ago
  You are making an opinion as to the definition of complex software. "Complex software" means different things to different people. Additionally, you've inserted a requirement of understanding one's systems that seems arbitrary and not universally applicable. Whatever happened to each his own?
  - teacup50 13y ago
    > You are making an opinion as to the definition of complex software. "Complex software" means different things to different people. "Complex" math or "complex" engineering means different things to different people, but "mathematical proof" and "deductive reasoning" do not. > Additionally, you've inserted a requirement of understanding one's systems that seems arbitrary and not universally applicable. It's not arbitrary, it's how we build systems that work, and work better. http://en.wikipedia.org/wiki/Engineering#Methodology http://en.wikipedia.org/wiki/Engineering#Methodology "By understanding the constraints, engineers derive specifications for the limits within which a viable object or system may be produced and operated." Without understanding one's system, it is impossible to understand its relation to one's constraints, and it is impossible to define the specifications within which that system operates. It's possible to build a car or an engine without understanding the math and science behind them, but it's impossible to build an engine of known specifications, it's impossible to provably assert that it operates within those specifications, and it's impossible to engage in directed design based on those specifications and defined operational limits. The best you can hope for is purely empirical evidence, and empirical evidence is of limited utility without a theoretical framework in which it can be applied to extrapolate further knowledge. As a result, systems designed and implemented without concern for understanding the theoretical basis of their operation invariably perform more poorly and cannot compete with systems designed and implemented based on building and applying a theoretically driven specification and understanding of constraints. To willfully prefer ignorance is objectively worse. > Whatever happened to each his own? Applied maths. It's either correct and verifiable or it's not.