Hacker News Reader

Comment by phamilton | Hacker News Reader

Web based is because JSON is always easier with dynamic types.

Rapid prototyping is because it requires less explicit up front design due to dynamic types.

Artificial Intelligence is because metaprogramming is easier in homoiconic languages.

I just don't buy the "dynamic types" lets you iterate faster argument. You are implicitly using types, and how often does that type change such that all the code you've written doesn't need to be updated anyways? And without the benefit of a compiler to tell you what you need to fix. A language like Go is fast to iterate, trivial to parse and serialize JSON, and simple enough that the tools let me make sweeping changes quite easily.

For a while now I have felt that the reason for the creation of languages like Python and Ruby is simply a response to the pain of one such as C++. Now that we have modern languages like Rust and Go, what is there to be gained from sacrificing a type system?

Iterate faster != Rapid prototyping.

The type system definitely helps with long term maintainability (and therefore fast iteration) but when your goal is to whip out a Proof of Concept for a greenfield project Ruby wins for me hands down. (Provided it isn't overly complex, defined as "can be completed in an hour or two").

Can you explain how types slow you down for whipping up a proof of concept?

Hitting an API endpoint, pulling data out of a database. Areas that already have an implicit schema require you to explicitly redefine that schema within your application.

I say this not just from personal preference, but I've proctored many timed coding challenges that were language agnostic. The challenge involved consuming data from a handful of API endpoints and compiling a response. Most statically typed solutions took twice the time of a dynamically typed one. We catered the time limit to the static case and it was a simple pass fail so no bonus points for doing it faster, but there was a strong advantage to the dynamic languages.

Note: This is very much alleviated with typed interchange formats like protobuf.

That coding challenge sounds like a far cry from developing even a prototype application. What was the skill level of the people doing it? Had they had experience in both dynamic and static types languages? What were the languages, Java or something modern?

Edit: I don't mean this to be snarky, I just feel that it is not a very good experiment to draw conclusions from.

We prepped them ahead of time telling them that they would need to produce an HTTP API that accepted requests and returned a response compiled from multiple HTTP endpoints. It's basically an orchestration layer, and I've done similar things in production many times. ("If we exposed X to the clients, we could allow action Y. Would action Y contribute to our goal of Z?" Instead of building a highly performant correct solution, we would do an on the fly derivation of the data needed, launch it for 5% and see the experiment results.)

It was for all candidates, meant to test ability to understand a problem and prototype a solution quickly.

Edit: most candidates did Java/Scala/Python/Ruby.

I think it's not so much a fundamental issue with "strongly typed" languages as it is the way "dynamic" languages are typically designed. For instance, Ruby doesn't care if you add an integral type to a floating point type; it'll give you something back. A strongly typed language will typically complain about this (the alternative is e.g. an onerously huge constellation of custom typeclasses/traits/whatever to support the full range of numeric intermingling), and Ruby could too, but its designers have made the decision that arithmetic operations should silently convert one argument to the type of the other, and return the answer as an instance of that type.

If I'm hacking together a quick and dirty prototype, I might not even care what type I get back from that operation as long as it's in the ballpark. Using Ruby means I just don't have to worry about it for longer than it takes me to type `a + b`. If I used Haskell, or Rust, or whatever, I have to be explicit. That's additional work, however minimal, and in my experience it really does add up.

Of course, if I'm writing code that's going to be in production, this sort of thing is highly irresponsible and using a strongly typed language will help me to avoid numerical errors that would not even be runtime errors in e.g. Ruby; they'd be silently swallowed instead. That's extremely valuable. And if development of my prototype is going to span multiple days or more, strong types and compile-time type checking are going to reduce my mental workload since I don't have to remember how everything fits together; it's explictly annotated throughout the code and checked every time I build.

> because JSON is always easier with dynamic types.

I think you mean JSON where the schema isn't defined. If you have full control over the JSON you're consuming, you control the schema. Typed languages aren't any worse than dynamic languages in this case.

> Rapid prototyping is because it requires less explicit up front design due to dynamic types.

Many types languages have a REPL environment specifically for this reason. In my experience, it's not any slower.

> Artificial Intelligence is because metaprogramming is easier in homoiconic languages.

I have no experience here, thus I will assume you are correct.

Complex, recursive JSON schemas are much more difficult even when the schema is known in most typed languages. Not impossible but I've definitely found myself changing my schema design because of friction in parsing JSON in Java.

   Artificial Intelligence is because 
   metaprogramming is easier in homoiconic 
   languages.

Homoiconicity is something you can add to any language, dynamically or statically typed, simple or complex, it doesn't matter. It used to be belived that only syntactically simple languages like Lisp are suitable for homoiconic extension, but this myth was destroyed by Walid Taha and his development of the MetaML family of languages.

For an overview of how to add homoiconicity to languages, see https://arxiv.org/abs/1602.06568

While I'm sure it's an interesting exercise, using a language that already had this property without any additional effort, still seems like the best path for most people trying to produce practical results.

I'm not sure I can agree. Every language that is being heavily used eventually acquires meta-programming extensions of some sort of other.

I'm really intrigued by your last point that "Artificial Intelligence is because metaprogramming is easier in homoiconic languages."

Can you elaborate on this? Why are or what about homoiconic lnagunages make them more suitable for metaprogramming and AI in general?

Thanks

Homoiconic languages are ones where the program itself is a valid data type. Lisps (like scheme) are great for this because your program is just a list. You can insert and remove code using the same tools you would for manipulating a list generally. It makes metaprogramming much simpler.

The relation to AI is an assumption that AI and metaprogramming are connected. This is probably debatable, but it makes sense to me (and others) that AI development would benefit from being able to easily generate code and modify itself, much like you or I would learn a new skill.

I don't think this is actually true for most of what people do with AI right now. Machine learning these days is something where you want strong, native machine level support for numeric programming on matrices. Possibly with GPU support. So a lisp based language wouldn't really help you much in the current environment.

If what you want is a system that rewrites itself, then you definitely want homoiconicity. It also helps if everything is one big expression.

Let's say you want to write an evolutionary algorithm that rearranges fragments of its code and runs it. More successful functions make it to the new generation. You want LISP for that.

Realistically, you could probably do this on any abstract syntax tree. But the problem is that unless your language is homoiconic, what you get back might not actually be valid in your language. So, homoiconicity gives you bidirectional support for rearranging the AST and still getting something you can read.

It's also just a lot easier to write something that looks at the code and does computation on it when that code is also data.

But, like I said, I'm not sure many people are actually doing this these days. It was popular back in the day. It's not clear that it's the right way to do things.

> [...] you want strong, native machine level support for numeric programming on matrices. Possibly with GPU support.

Scheme is a popular extension language. You could use it the same way Torch uses Lua.

Thanks, sure, this makes sense given the origins of LISP. Cheers.

Why is JSON easier with dynamic types? In my experience, there's always a schema of some kind.

Your first two points are also met by optionally typed languages.

Oh yeah, because those are a dime a dozen and available almost everywhere! /s

I'd argue that optionally typed languages are dynamically typed. Typescript at runtime is dynamically typed, same with Erlang. Perhaps not always true, but usually the type system provides static analysis which is help but not sufficient to provide guarantees.

Dynamic typing and static typing can coexist in the same language. C# is generally statically typed, but the more recent versions support the dynamic keyword - at which point you're statically typing things to be dynamically typed. Typescript of course goes the other way - adding static typing features to otherwise dynamically typed Javascript.

...the first thing I do when encountering JSON in TypeScript these days is to add type definitions to describe the schema. If I have a hard time describing the schema to TypeScript, I'm going to have an even worse time trying to keep it straight myself.

Reply on news.ycombinator.com