Live data from Hacker News

Advanced programming languages (2009)

matt.might.net

131–140 of 208 posts

Re: Advanced programming languages (2009)

#131

Earlier quoted context omitted.

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.

Re: Advanced programming languages (2009)

#132
post #64

Earlier quoted context omitted.

PL theorists generally talk about whether or not syntactic terms (as opposed to runtime values) have types. Scheme is untyped by that definition.

PL theorists don't get own the definition of what "type" means. Type pervades computing. A directory is a different type from a file or character device. A JPEG is a different file type from a PNG. You have MIME types in your e-mail. An ICMP packet is a different type from a TCP datagram. Machine language instruction sets have types: pointers, signed and unsigned words of various sizes, floating-point values. "Type"…

A PL theorist would note that most of the time when people talk about ‘types’, that they really mean ‘classes’, and that all of those things your mentioned would be considered to be the latter. Types are rather the elements of your program that correspond directly to logical propositions (which your program proves to be true).

Re: Advanced programming languages (2009)

#133
post #8

I personally would really hesitate before picking a language that will be hard to hire for to build a business around. Yes, you'll be more productive in the short-term, but a business is more than just code and you will need to wear those hats too before you'll have enough understanding and resources to hire those out. At this point, I'm fairly certain your first hire should be someone to take the engineering load of…

"I personally would really hesitate before picking a language that will be hard to hire for to build a business around" Unfortunately, this is HN so we know you're wrong: http://www.paulgraham.com/avg.html

Not everyone here accepts PG articles as infallible scripture, and many people have lots of experience to back up their disagreement.

(I agree with PG on this issue.)

Re: Advanced programming languages (2009)

#134
post #121

Earlier quoted context omitted.

I can recommend Scala: - It is mature and rock-solid, but still manages to evolve, fix issues and simplify/remove features. Most other languages are purely additive, meaning you will have to carry on all the baggage since the languages' inception. - It is a language which is interested in identifying the best way to solve common programming issues and spares you with all this ideological "OOP/FP is bad" bullshit. - I…

Once you have had real Hindley-Milner Scala feels painfully primitive. Just go straight to OCaml.

I'm afraid I disagree. I went from Ocaml to Scala. While full type inference is nice, it's a minor issue in practise, but the vastly bigger library ecosystem that Scala has (due to being a JVM language) isn't. Object orientation also works better in Scala than Ocaml.

Re: Advanced programming languages (2009)

#135
post #121

Earlier quoted context omitted.

I can recommend Scala: - It is mature and rock-solid, but still manages to evolve, fix issues and simplify/remove features. Most other languages are purely additive, meaning you will have to carry on all the baggage since the languages' inception. - It is a language which is interested in identifying the best way to solve common programming issues and spares you with all this ideological "OOP/FP is bad" bullshit. - I…

Once you have had real Hindley-Milner Scala feels painfully primitive. Just go straight to OCaml.

Can you expand on this for someone who is not familiar with Hindley-Milner typing?

Re: Advanced programming languages (2009)

#136

Earlier quoted context omitted.

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

Re: Advanced programming languages (2009)

#138

Earlier quoted context omitted.

Knowing Java won't help you much in learning Scala. It's the functional programming parts that will trip you up if you haven't done that before, and this is the most valuable part to learn. I use Scala every day, and it was easy to learn; but I suspect that was because I did a lot of functional programming before that.

But ins't one of the nice parts about Scala that you can use it strictly for OO programming, use it for strictly for FP or both?

Yes, that's definitely one of the great things about Scala.

If you come from an OO background, I recommend to avoid using Scala's functional features at the start. Just treat Scala as a nice, conventional OO language until you are comfortable with the language. Then, slowly use some of the more advanced features. Case classes and pattern matching are easy and powerful next steps.

Enjoy the ride!

Re: Advanced programming languages (2009)

#139

Earlier quoted context omitted.

Reasonability. In an age where billion dollar companies are gutted by 16yo hackers on a monthly basis, it's worth the effort to build strong, secure systems that can be formally reasoned about.

Its disengenious to imply that functional cant be as insane as procedural. Also, everything is strong and securw until vulnerabilities are found (heartbleed as an example). Its in the hackers best interest to never let these vulnerabilities known. Also since there are many less eyes on less popular languages, vulnerabilities will take more time to be discovered.

The combination of stronger type systems (especially dependent typing), less error-prone design (no manual memory management, no mutation, no global state, no loops/off-by-one errors), separated side effects (crashing during computation won't break things, less places for outside interference/external failure, etc.), and better error handling (no null, usually no exceptions meaning you have to encode failure into the return value itself without losing type information) solves many common bugs in imperative code.

Re: Advanced programming languages (2009)

#140

Earlier quoted context omitted.

Scala makes it really easy to call a blocking function using a future with a configurable execution context. I don't see why one would run out of threads. Currently we use the Typesafe supported Slick library but the mechanism is the same. Maybe I'm missing your point but as a professional Scala programmer I've never run into a problem with Jvm or Java integration

I've done it naively with a mongo driver. Just wrapping it in a future doesn't cut it, as you said you have to configure a separate execution context and even that context is finite. Or use a blocking future which has other implications. It's more a point against the "strictly better than Java, use the bits you want as you you go" point in the article. You have to understand Scala's execution model and make sure you…

It's also a real pain to call Scala code from Java, which makes blending Java and Scala code in a project, or adding Scala code to an existing Java project, much less attractive.
Post reply on HN