I am a bit surprised Clojure and Clojurescript are not in this list. I guess Clojure still was a bit young at the time this article was written. Within past few years Clojure has become extremely popular.
Advanced programming languages (2009)
161–170 of 208 posts
Re: Advanced programming languages (2009)
#162I would argue that a well-known language is fairly expressive in the sense that it is well-known. Imagine English itself was a programming language - this is the best. But for now I would recommend using those who are commonly used in the common platforms of interest (Java, javascript, C etc)
> Imagine English itself was a programming language That's a terrible idea. https://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffal...
Wait for someone to write it in Perl.
Re: Advanced programming languages (2009)
#163This post is very fortuitous for me. I've been looking to learn a functional language and I had more or less narrowed my options to Haskell, OCaml and Scala. I liked the breakdown between these languages and the resources. Can anyone who programs in Haskell or OCaml regularly tell me the current state of standard and third party library support? I'm very attracted to Scala because it has JVM support, which sounds fan…
We write OCaml professionally. In case you find it useful to browse real world, battle-tested code, here's our main repo (there are others, but this is the largest): https://github.com/libguestfs/libguestfs There is an introduction/overview of the source here: http://libguestfs.org/guestfs-hacking.1.html
Re: Advanced programming languages (2009)
#164Earlier quoted context omitted.
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…
Type systems - already available in the most popular languages
no memory management - c++, go, java come to mind
No mutation - has a side effect which you probably will never mention. But it will become important as the internet of things gets smaller
No global state - in what environments would that ever be an encouraged paradigm? Javascript?
No loops/off by one - you still need loops, they are just recursive. The difference is you need to jump around to figure out what the hell is going on instead of reading it top to bottom
Better error handling - nothing you just said seems better to me
Sure, there are many thing I like about functional languages. I like how you can create a tree to reason about you code to the point it looks like a flowchart. It has forced me to question my own coding style and how I compartmentalize and where I can run things in parralel. How infinite lists, streams and arrays can all be considered the same interface. But I think there is room for growth.
- forces me to the bottom of a document to find out where it starts
- uses obscure language in order to avoid oop
- Cannot use symbols represent the start and end of a typed object constructor with a single string argument (regex, jsx, queries, etc)
Re: Advanced programming languages (2009)
#165This post is very fortuitous for me. I've been looking to learn a functional language and I had more or less narrowed my options to Haskell, OCaml and Scala. I liked the breakdown between these languages and the resources. Can anyone who programs in Haskell or OCaml regularly tell me the current state of standard and third party library support? I'm very attracted to Scala because it has JVM support, which sounds fan…
We write OCaml professionally. In case you find it useful to browse real world, battle-tested code, here's our main repo (there are others, but this is the largest): https://github.com/libguestfs/libguestfs There is an introduction/overview of the source here: http://libguestfs.org/guestfs-hacking.1.html
Heh, libguestfs helped me out a couple of years ago.. Never realised it was OCaml. Nice! (Noobing myself through OCaml & F# right now, so this will be an interesting reference to study :) )
Re: Advanced programming languages (2009)
#166Earlier 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?
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.
Re: Advanced programming languages (2009)
#167Earlier quoted context omitted.
I am so freaking excited about Scala Native. I haven't been so genuinely excited and enthusiastic about something for such a long time, but Scala Native is so awesome. I feel like turning Scala into a cross-platform language is the best idea possible. I'd love to see Scala someday be able to just dump out WebAssembly, or JVM bytecode, or LLVM IR, or whatever the next "hip" format is, while keeping the language the sa…
What is Scala native? Is there a Scala that doesn't rely on the JVM for hosting?
Re: Advanced programming languages (2009)
#168Earlier quoted context omitted.
We write OCaml professionally. In case you find it useful to browse real world, battle-tested code, here's our main repo (there are others, but this is the largest): https://github.com/libguestfs/libguestfs There is an introduction/overview of the source here: http://libguestfs.org/guestfs-hacking.1.html
Heh, libguestfs helped me out a couple of years ago.. Never realised it was OCaml. Nice! (Noobing myself through OCaml & F# right now, so this will be an interesting reference to study :) )
It's a mix. The library is C, pure and simple. But we use OCaml to generate a lot of that C - which I think is a very under-used but powerful technique giving you the best of both worlds. We also use OCaml to generate programming language bindings to the C API, so that when a new API is added you simply have to recompile and the API is available in every supported language (about a dozen so far).
However the main use of OCaml is in the higher-level utilities, for example virt-v2v (https://github.com/libguestfs/libguestfs/tree/master/v2v) and virt-builder (https://github.com/libguestfs/libguestfs/tree/master/builder) are substantial OCaml programs.
Re: Advanced programming languages (2009)
#169Earlier quoted context omitted.
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…
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.
Re: Advanced programming languages (2009)
#170What's up with functional languages nowadays? The exists since the dawn of humanity, but they are getting very trendy lately. Is it just my perception? Is it a HN thing? (I've been a reader for just some months)
Concepts that originated in functional languages have been slowly percolating to everyday use via dynamic languages, things like first class functions, map/reduce, closures, lambda etc. Bouncing these buildings blocks in your head for 10 years or so makes the rest of the FP concepts look pretty natural and a logical next step even if you're just joe programmer in the trenches.