5 ms·

Just going to point out here that you are conflating Javascript problems with dynamic language problems. Try Clojure, a well designed dynamic language, and you'

Just going to point out here that you are conflating Javascript problems with dynamic language problems. Try Clojure, a well designed dynamic language, and you'll find you are a lot more productive with it than any statically typed language. Indeed over the weekend I was able to design and build a GUI DSL, layout system, model-view databinding, command event system, and serialisation/deserialisation logic for a side project of mine. This sort of stuff would have taken weeks of effort in a static language.

wtetzner 9y ago
Clojure is a fine language, and I wrote it professionally for a few years. However, I don't see why this would be true: > This sort of stuff would have taken weeks of effort in a static language. I've also written plenty of things in typed languages, and in many ways they can be faster to develop in than dynamic languages. Of course, you do need to change the way you program a bit to really take advantage of types. I think the main advantage Clojure has over most typed languages is macros, but there is work being done to rectify even that.
- hacker_9 9y ago
  I used to think this, until I used Clojure. I'm surprised you used it professionally and have that mindset, I write far less code in Clojure and get far more done. The productivity gains are amazing, especially when I can just upload new code on the fly as the program is running.
  - nickpsecurity 9y ago
    It's because it's a LISP with good ecosystem. LISP is already strongly, but dynamically, typed from what I'm told. So, you get quite a bit of benefit. You could probably do the same in a statically- or gradually-typed LISP. Main difference is you'll catch a few more interface errors without tests. Also, if using specs or types, one can do automated generation of testing, enabled better static analysis, and/or improve optimization in compilers. Basically, the tools know a bit more about what you're trying to do.
  - wtetzner 9y ago
    Part of the issue is maintenance. Coming back to code you haven't worked on in a while can require more time to load back into your head than a typed language. And speaking from experience [1], refactoring in a typed language also tends to go more smoothly. > I'm surprised you used it professionally and have that mindset I used to have your mindset when I first started working with Clojure :) Keep in mind that not all typed languages are created equal. Clojure is still much better than Java. But I find I'm quite productive with OCaml, due in large part to the simple but powerful type system, plus the fantastic module system. OCaml does have some drawbacks compared to Clojure, but they're not related to static typing. The main disadvantages are the macro system (even the new extension point stuff is cumbersome compared to a proper macro system) and the smaller library ecosystem. [1] I've done a lot of refactoring in Clojure, and while it wasn't terrible, types can help a lot. [Edit] To be clear, I do think Clojure has a lot going for it, but I don't think any of it's advantages are due to being dynamically typed, and there's no reason a statically typed language can't have the same benefits.
dahauns 9y ago
Throwing that back at you: Don't conflate Java problems with static language problems...
- nickpsecurity 9y ago
  Java almost always lost in productivity or correctness studies on programs of significant size unless it was going up against monstrosities like C or C++. So, yeah, it's a holdover from Worse is Better effect and corporate sponsorship rather than illustrative of something great in static 3GL's.
weberc2 9y ago
Does Clojure support something that JS doesn't, or is it mostly that JS has warts that introduce errors that slow you down? I would think that Clojure is more or less a subset of JS, and if you're disciplined about using that subset, you should be equally productive in either language. Also, a frequent problem I have in JS and Python is that they don't scale very well; type documentation must be updated manually and inevitably becomes incorrect with time; determining the type of a return is always a matter of extensive grepping, etc. With most statically typed languages, the IDE can tell you this right away, but in the worst case you just look at the function signature; does Clojure have a solution for this problem?
- hacker_9 9y ago
  Thinking of Clojure as a subset of JS is a new one. It's more accurate to say JS is a badly implemented Lisp! These are the main reasons Clojure works so well: 1. It is a Lisp: The only type is the 'list', and in Clojure you also have 'maps' too (basically a dictionary in JS). That's it. Any object in JS is a map in Clojure, which keeps everything nice and simple. The main power of this is you only ever need to support lists or maps in your functions, and then your functions work for every data structure you ever create! For example clojure.core ships with 'get-in' 'assoc-in', 'diff' etc, all functions that work on your structures no matter how complex. 2. It is a functional language: JS is imperative, meaning you have to fit your ideas to the language, breaking everything down into for loops and if statements. With Clojure you fit the language to the idea, and think in data transformations instead. Then you create a set of functions that deal with that problem specifically, all wrapped up in single namespace. For example a 'tilemap' ns that contains a set of functions for converting to/from screen and grid coordinates. Or getting the neighbours of a specified tile from the 2d array. The end result is a custom DSL that reads almost like English. 3. It is 'immutable by default': All data structures are persistent. The problems you have with scaling in JS and Python is all because of mutable local and global state, as it becomes very difficult to know what is changing what. Clojure doesn't have this problem, as values can't be edited, only new ones returned. There is still mutability of course, but it is restricted to maybe 10 locations in your codebase. The mental burden this lifts from your shoulders cannot be understated. 4. It has a REPL: Let me ask how much effort you think building a HTML editor is? Or the UI designer in Visual Studio? With Clojure, I can just make edits to the GUI code on the fly and press F10 and voila the changes appear in-app. Instant editor, for free. This is what i was doing the other day; editing my GUI code (re-arranging controls, changing positions and sizes) and then immediately inspecting the result in the running program. The productivity gains are huge when you remove the laborious 'write code, wait for build, navigate to place in the app, finally test your changes, find error, end program, change code, repeat' cycle from your workflow. 5. Macros: Lisp macros are just Lisp code again. Literally the whole language available to you at compile time. The clojure.async library for example uses this to provide Go style channels for async programming. It means you can write code that looks great, and still compiles down to something performant at the end.
hota_mazi 9y ago
> This sort of stuff would have taken weeks of effort in a static language. For you, maybe. For someone familiar with that static language? They might have gone faster. Productivity in a language is highly subjective so it shouldn't come into the equation if you're trying to compare statically and dynamically typed languages.
- hacker_9 9y ago
  For the record, I've been a C# developer for 12 years. A Clojure dev for about ~6 months. Also, productivity is not subjective.
  - nickpsecurity 9y ago
    It is unless you're measuring the differences with an apples to apples comparison. Examples of how it was done in case studies or empirical research on software development: 1. Features developed by teams with different languages. 2. Features per day per team. 3. Lines of code that took. 4. Defect rate found after all testing and review. 5. Time taken to modify N lines of existing code. 6. Defects introduced during modifications. 7. Overall productivity rate at end of project for each that factors in initial lines of code minus what was reworked to get real lines of correct code produced averaged across each day usually. Clojure vs Typed Racket vs commercial Smalltalk vs Ocaml or Haskell w/ meta-programming might tell use something objectively. Right now, you have no measurements on typed alternatives similar to your current tool. Your claim that it's more productive is highly subjective albeit I'll give you that prior measurements with small, sample size confirmed strongly-typed, dynamic languages give major productivity boost over statically-typed 3GL's. LISP and Smalltalk winning in that area over predecessors to C#. Your language vs similar ones remains worth measuring, though.
  - weberc2 9y ago
    To be fair, C# is not the pinnacle of statically typed languages. Go is quite a lot nicer from a productivity perspective, and but there is also Haskell and OCaml if you want a more expressive type system.

wtetzner 9y ago

Clojure is a fine language, and I wrote it professionally for a few years. However, I don't see why this would be true: > This sort of stuff would have taken weeks of effort in a static language. I've also written plenty of things in typed languages, and in many ways they can be faster to develop in than dynamic languages. Of course, you do need to change the way you program a bit to really take advantage of types. I think the main advantage Clojure has over most typed languages is macros, but there is work being done to rectify even that.

hacker_9 9y ago
I used to think this, until I used Clojure. I'm surprised you used it professionally and have that mindset, I write far less code in Clojure and get far more done. The productivity gains are amazing, especially when I can just upload new code on the fly as the program is running.
- nickpsecurity 9y ago
  It's because it's a LISP with good ecosystem. LISP is already strongly, but dynamically, typed from what I'm told. So, you get quite a bit of benefit. You could probably do the same in a statically- or gradually-typed LISP. Main difference is you'll catch a few more interface errors without tests. Also, if using specs or types, one can do automated generation of testing, enabled better static analysis, and/or improve optimization in compilers. Basically, the tools know a bit more about what you're trying to do.
- wtetzner 9y ago
  Part of the issue is maintenance. Coming back to code you haven't worked on in a while can require more time to load back into your head than a typed language. And speaking from experience [1], refactoring in a typed language also tends to go more smoothly. > I'm surprised you used it professionally and have that mindset I used to have your mindset when I first started working with Clojure :) Keep in mind that not all typed languages are created equal. Clojure is still much better than Java. But I find I'm quite productive with OCaml, due in large part to the simple but powerful type system, plus the fantastic module system. OCaml does have some drawbacks compared to Clojure, but they're not related to static typing. The main disadvantages are the macro system (even the new extension point stuff is cumbersome compared to a proper macro system) and the smaller library ecosystem. [1] I've done a lot of refactoring in Clojure, and while it wasn't terrible, types can help a lot. [Edit] To be clear, I do think Clojure has a lot going for it, but I don't think any of it's advantages are due to being dynamically typed, and there's no reason a statically typed language can't have the same benefits.

dahauns 9y ago

Throwing that back at you: Don't conflate Java problems with static language problems...

nickpsecurity 9y ago
Java almost always lost in productivity or correctness studies on programs of significant size unless it was going up against monstrosities like C or C++. So, yeah, it's a holdover from Worse is Better effect and corporate sponsorship rather than illustrative of something great in static 3GL's.

weberc2 9y ago

Does Clojure support something that JS doesn't, or is it mostly that JS has warts that introduce errors that slow you down? I would think that Clojure is more or less a subset of JS, and if you're disciplined about using that subset, you should be equally productive in either language. Also, a frequent problem I have in JS and Python is that they don't scale very well; type documentation must be updated manually and inevitably becomes incorrect with time; determining the type of a return is always a matter of extensive grepping, etc. With most statically typed languages, the IDE can tell you this right away, but in the worst case you just look at the function signature; does Clojure have a solution for this problem?

hacker_9 9y ago
Thinking of Clojure as a subset of JS is a new one. It's more accurate to say JS is a badly implemented Lisp! These are the main reasons Clojure works so well: 1. It is a Lisp: The only type is the 'list', and in Clojure you also have 'maps' too (basically a dictionary in JS). That's it. Any object in JS is a map in Clojure, which keeps everything nice and simple. The main power of this is you only ever need to support lists or maps in your functions, and then your functions work for every data structure you ever create! For example clojure.core ships with 'get-in' 'assoc-in', 'diff' etc, all functions that work on your structures no matter how complex. 2. It is a functional language: JS is imperative, meaning you have to fit your ideas to the language, breaking everything down into for loops and if statements. With Clojure you fit the language to the idea, and think in data transformations instead. Then you create a set of functions that deal with that problem specifically, all wrapped up in single namespace. For example a 'tilemap' ns that contains a set of functions for converting to/from screen and grid coordinates. Or getting the neighbours of a specified tile from the 2d array. The end result is a custom DSL that reads almost like English. 3. It is 'immutable by default': All data structures are persistent. The problems you have with scaling in JS and Python is all because of mutable local and global state, as it becomes very difficult to know what is changing what. Clojure doesn't have this problem, as values can't be edited, only new ones returned. There is still mutability of course, but it is restricted to maybe 10 locations in your codebase. The mental burden this lifts from your shoulders cannot be understated. 4. It has a REPL: Let me ask how much effort you think building a HTML editor is? Or the UI designer in Visual Studio? With Clojure, I can just make edits to the GUI code on the fly and press F10 and voila the changes appear in-app. Instant editor, for free. This is what i was doing the other day; editing my GUI code (re-arranging controls, changing positions and sizes) and then immediately inspecting the result in the running program. The productivity gains are huge when you remove the laborious 'write code, wait for build, navigate to place in the app, finally test your changes, find error, end program, change code, repeat' cycle from your workflow. 5. Macros: Lisp macros are just Lisp code again. Literally the whole language available to you at compile time. The clojure.async library for example uses this to provide Go style channels for async programming. It means you can write code that looks great, and still compiles down to something performant at the end.

hota_mazi 9y ago

> This sort of stuff would have taken weeks of effort in a static language. For you, maybe. For someone familiar with that static language? They might have gone faster. Productivity in a language is highly subjective so it shouldn't come into the equation if you're trying to compare statically and dynamically typed languages.

hacker_9 9y ago
For the record, I've been a C# developer for 12 years. A Clojure dev for about ~6 months. Also, productivity is not subjective.
- nickpsecurity 9y ago
  It is unless you're measuring the differences with an apples to apples comparison. Examples of how it was done in case studies or empirical research on software development: 1. Features developed by teams with different languages. 2. Features per day per team. 3. Lines of code that took. 4. Defect rate found after all testing and review. 5. Time taken to modify N lines of existing code. 6. Defects introduced during modifications. 7. Overall productivity rate at end of project for each that factors in initial lines of code minus what was reworked to get real lines of correct code produced averaged across each day usually. Clojure vs Typed Racket vs commercial Smalltalk vs Ocaml or Haskell w/ meta-programming might tell use something objectively. Right now, you have no measurements on typed alternatives similar to your current tool. Your claim that it's more productive is highly subjective albeit I'll give you that prior measurements with small, sample size confirmed strongly-typed, dynamic languages give major productivity boost over statically-typed 3GL's. LISP and Smalltalk winning in that area over predecessors to C#. Your language vs similar ones remains worth measuring, though.
- weberc2 9y ago
  To be fair, C# is not the pinnacle of statically typed languages. Go is quite a lot nicer from a productivity perspective, and but there is also Haskell and OCaml if you want a more expressive type system.