4 ms·

They are languages for quick prototyping (consider Arc's philosophy - a core language for a quick, bottom-up prototyping). Most of the time, the prototype is g

They are languages for quick prototyping (consider Arc's philosophy - a core language for a quick, bottom-up prototyping). Most of the time, the prototype is good enough for production. If not - there are implementation languages (C, C++). So, I cannot see any problem.

namanbharadwaj 11y ago
The prototype may be good enough for production, but is probably not very maintainable. When you need a large team to be able to fix bugs and add features, static typing often wins. If you don't choose static typing early, you might never be able to again.
- dschiptsov 11y ago
  Dynamic code could be order of magnitude more compact and readable. schiptsov@MSI-U270:~/arc3.1$ du -sh . 472K . Anyway, at least for me, static typing is the must is a marketing meme from the time of Java madness. And if I really need it I could re-write my prototype in no time (like translating a ready book from one language to another).
  - deleted 11y ago
    [deleted]
  - dschiptsov 11y ago
    What's wrong with this?)) Don't know how this very site has been made? Ignorance is strength.
    - learc83 11y ago
      Hacker News is a relatively small site with very few features that is managed by a very small team, and up until a year or so ago often ran rather poorly. I'm not sure it's the best argument for using a dynamically typed language. That being said, I say use what works for you. Dynamic typing is obviously a viable solution, and there are plenty of successful projects that use use dynamically typed languages. However, after almost 10 years of using dynamically typed languages I can tell you that I no longer believe the trade-off is worth it. Even on small single person side projects, I personally think that after a thousand lines of code or so, the benefits of static typing outweigh the cost.
      - dschiptsov 11y ago
        The point about this site and Ark is that they (pg and rtm) practice what they preach. It is, basically, a real project based on philosophy from famous "beating an average" essay and the "On Lisp" books - quick, bottom-up process of bootstrapping of a several layers of DSLs (idea popularized by SICP and refined in On Lisp) - with a new dialect of Lisp as a by-product.) Everything in a half of Mb of text. OK, they reused mzsheme's runtime, because runtime is hard (even clojure delegated everything to JRE) but nevertheless, Arc and this site are remarkably successful examples of real world project with all the benefits of dynamic languages. Sorry for the delay, we had a quake that day.
  - deleted 11y ago
    [deleted]
- neonfreon 11y ago
  I always hear this: "statically typed languages make for more maintainable projects than dynamically typed languages." Is there any empirical evidence to back this up?
  - dschiptsov 11y ago
    If you are employed at a bank to manage a small team of Java coders, how could it be otherwise?)
  - angersock 11y ago
    COBOL was statically typed, and they've been maintaining those programs for decades!
    - dschiptsov 11y ago
      What is wrong with those Common Lisp programs?)
  - deleted 11y ago
    [deleted]
deleted 11y ago
[deleted]
Havvy 11y ago
I see a problem. Neither C nor C++ have garbage collection and other similar runtime features that every scripting language has. As such, if you rely a lot on these features, you could run into issues when translating into a lower level - either in implementation or in memory safety.
- dschiptsov 11y ago
  OK, but simple, straight-forward memory management is not that hard. I could even rip out pool-allocations and buffers from nginx/src or reuse lib9 and frineds (which were at the core of golang before 1.5) There is also Boehm GC. And if I didn't mentioned Golang It doesn't mean that I am unaware of its existence.)
- GeneralMayhem 11y ago
  Modern C++ actually makes for a pretty nice prototyping language if you use auto and std::shared_ptr everywhere, turn on RTTI, and make every method virtual. That gives you mostly-hidden compile-time type induction, explicit type-based dispatch, reference-counted garbage collection, and extensible classes. Then, once you've got things working, you can refine the ownership semantics and internal interfaces.
  - dschiptsov 11y ago
    No, thank you.)

namanbharadwaj 11y ago

The prototype may be good enough for production, but is probably not very maintainable. When you need a large team to be able to fix bugs and add features, static typing often wins. If you don't choose static typing early, you might never be able to again.

dschiptsov 11y ago
Dynamic code could be order of magnitude more compact and readable. schiptsov@MSI-U270:~/arc3.1$ du -sh . 472K . Anyway, at least for me, static typing is the must is a marketing meme from the time of Java madness. And if I really need it I could re-write my prototype in no time (like translating a ready book from one language to another).
- deleted 11y ago
  [deleted]
- dschiptsov 11y ago
  What's wrong with this?)) Don't know how this very site has been made? Ignorance is strength.
  - learc83 11y ago
    Hacker News is a relatively small site with very few features that is managed by a very small team, and up until a year or so ago often ran rather poorly. I'm not sure it's the best argument for using a dynamically typed language. That being said, I say use what works for you. Dynamic typing is obviously a viable solution, and there are plenty of successful projects that use use dynamically typed languages. However, after almost 10 years of using dynamically typed languages I can tell you that I no longer believe the trade-off is worth it. Even on small single person side projects, I personally think that after a thousand lines of code or so, the benefits of static typing outweigh the cost.
    - dschiptsov 11y ago
      The point about this site and Ark is that they (pg and rtm) practice what they preach. It is, basically, a real project based on philosophy from famous "beating an average" essay and the "On Lisp" books - quick, bottom-up process of bootstrapping of a several layers of DSLs (idea popularized by SICP and refined in On Lisp) - with a new dialect of Lisp as a by-product.) Everything in a half of Mb of text. OK, they reused mzsheme's runtime, because runtime is hard (even clojure delegated everything to JRE) but nevertheless, Arc and this site are remarkably successful examples of real world project with all the benefits of dynamic languages. Sorry for the delay, we had a quake that day.
- deleted 11y ago
  [deleted]
neonfreon 11y ago
I always hear this: "statically typed languages make for more maintainable projects than dynamically typed languages." Is there any empirical evidence to back this up?
- dschiptsov 11y ago
  If you are employed at a bank to manage a small team of Java coders, how could it be otherwise?)
- angersock 11y ago
  COBOL was statically typed, and they've been maintaining those programs for decades!
  - dschiptsov 11y ago
    What is wrong with those Common Lisp programs?)
- deleted 11y ago
  [deleted]

deleted 11y ago

[deleted]

Havvy 11y ago

I see a problem. Neither C nor C++ have garbage collection and other similar runtime features that every scripting language has. As such, if you rely a lot on these features, you could run into issues when translating into a lower level - either in implementation or in memory safety.

dschiptsov 11y ago
OK, but simple, straight-forward memory management is not that hard. I could even rip out pool-allocations and buffers from nginx/src or reuse lib9 and frineds (which were at the core of golang before 1.5) There is also Boehm GC. And if I didn't mentioned Golang It doesn't mean that I am unaware of its existence.)
GeneralMayhem 11y ago
Modern C++ actually makes for a pretty nice prototyping language if you use auto and std::shared_ptr everywhere, turn on RTTI, and make every method virtual. That gives you mostly-hidden compile-time type induction, explicit type-based dispatch, reference-counted garbage collection, and extensible classes. Then, once you've got things working, you can refine the ownership semantics and internal interfaces.
- dschiptsov 11y ago
  No, thank you.)