Earlier quoted context omitted.
For me it's typically weighted less on the type system and more the fact that I don't need to wait for a compiler or use any fancy tools to get a quick idea realized.
If you remove a lot of the cruft and redundancy and add memory management, a statically typed language with fast compiles can have some of the benefits of a dynamic language. If I could have a dynamic language, and static typing, that would be the best of both worlds. However, gradual typing doesn't seem to have caught on.
If You're Not Writing a Program, Don't Use a Programming Language [video]
31–40 of 288 posts
Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#32With all due respect to Leslie Lamport his "what could be more beautiful" explanation of Euclid's algorithm is no easier for me to make sense of than these[0] various implementations. For a "complex" problem[1] you cannot write a unified field definition[2] before the fact. Otherwise the problem would have to be merely complicated (most sufficiently useful systems are complex). The easiest way humans can make sense o…
Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#33Lamport is famous in part for his work on LaTeX, the document typesetting language. It is Turing complete. Should no one write papers in LaTeX?
Also, the rest of your comment doesn't make any sense, either.
Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#34I hope TLA+ gains more popularity. It's an interesting technology.
Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#35I haven't watched the full talk, so let me know if this gets explored by Lamport, but... Here's a thought: PL researchers seem to generally agree that typed languages are superior to untyped languages, yet programmers tend to prefer untyped languages to typed languages, to the point where Java and C++ have the fanciest type systems in common use, with ML being the closest thing to an academic language that gets signi…
With the exception of JavaScript, I only use dynamic languages for throw away scripts.
I had lots of fun with Lisp and Smalltalk, but can't imagine using them with the team sizes I usually work with.
Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#36Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#37Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#38I believe these are the kinds of ideas that might actually create a genuine engineering culture in software development. Until we start applying this kind of rigor to our work, I don't believe the title of "Software Engineer" is justified. It doesn't have to be TLA+; it doesn't have to be any particular tool or technology or pattern or whatever. But the attitude that rigor and formal technique is worth the additional…
I disagree that engineering is the best approach to writing software. I think this is the fundamental difference between people who prefer static vs dynamic typing. People who prefer static typing are more likely to say that one solution is more "correct" than the other, whereas dynamic typing allows more flexibility. I see writing software to be similar to writing music. Music has rules and structure, but leaves roo…
Design your product with as much free thought and creativity as you please, but never let yourself believe your actual code is art. That - among many other outcomes - is how your platform gets compromised and your customers' identities stolen - not to mention how the successors to your job end up cursing your name and wasting time and money replacing your code wholesale.
Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#39Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#40With all due respect to Leslie Lamport his "what could be more beautiful" explanation of Euclid's algorithm is no easier for me to make sense of than these[0] various implementations. For a "complex" problem[1] you cannot write a unified field definition[2] before the fact. Otherwise the problem would have to be merely complicated (most sufficiently useful systems are complex). The easiest way humans can make sense o…