Hacker News Reader

Comment by dschiptsov | Hacker News Reader

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.

View on HN

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.

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.)

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.

No, thank you.)

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.

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).

What's wrong with this?))

Don't know how this very site has been made? Ignorance is strength.

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.

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.

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?

If you are employed at a bank to manage a small team of Java coders, how could it be otherwise?)

COBOL was statically typed, and they've been maintaining those programs for decades!

What is wrong with those Common Lisp programs?)

Reply on news.ycombinator.com