4 ms·
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. Ar
by phamilton 10y ago
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.
- jlg23 10y agoYour first two points are also met by optionally typed languages.
- shrugger 10y agoOh yeah, because those are a dime a dozen and available almost everywhere! /s
- phamilton 10y agoI'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.
- MaulingMonkey 10y agoDynamic 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.
- edgyswingset 10y ago> 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.
- phamilton 10y agoComplex, 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.
- deleted 10y ago[deleted]
- hesdeadjim 10y agoI 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?
- phamilton 10y agoIterate 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").
- peteretep 10y agoCan you explain how types slow you down for whipping up a proof of concept?
- phamilton 10y agoHitting 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.
- bogomipz 10y agoI'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
- phamilton 10y agoHomoiconic 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.
- bhntr3 10y agoI 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.
- teamhappy 10y ago
- mafribe 10y agoArtificial 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 https://arxiv.org/abs/1602.06568
- hetman 10y agoWhile 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.
- mafribe 10y agoI'm not sure I can agree. Every language that is being heavily used eventually acquires meta-programming extensions of some sort of other.
- douche 10y agoWhy is JSON easier with dynamic types? In my experience, there's always a schema of some kind.