Live data from Hacker News

Modern Language Wishlist

lispcast.com

41–50 of 75 posts

Re: Modern Language Wishlist

#41
hmm, what exactly does he mean by data-oriented programming?

iirc that's something where you don't store data chopped up into objects, but have arrays that keep all the data of one "aspect" of all "objects"... or something like that. something game programmers would use, helps avoid cache misses.

is that what he was talking about? if so, what does it have to do with macros?

Re: Modern Language Wishlist

#42
post #37

Earlier quoted context omitted.

Actually, from a math perspective, it's kind of nonsensical to talk about type conversion at all. That is, 3, 3.0, and 3/1 are purely notational differences, and all three represent exactly the same object. Since math is theoretically infinite precision, the way you write a number has no impact on the way operations like division act on it, making whether it belongs to Z, or just Q or R a moot point. Now, if you rest…

Kind of. But you might say that rational numbers are ordered pairs of integers and positive integers, real numbers are Cauchy sequences of rationals, and complex numbers are ordered pairs of real numbers, and the real number 3 can't be added to (2+i) without converting it to a complex number first.

Those are all valid ways of conceptualizing those sets, but I don't think it changes the point I was making. The real number 3 doesn't need to be "converted" to a complex number to be added to 2+i. 3 is always both a real number and a complex number, which may be represented as either 3 or 3+0*i, and either way gives 5+i when added to 2+i. All the latter notation really does is clarifies what domain you're currently working in, and even so, I've never seen anyone write it out explicitly.

Type conversion is more like if you had the written number 3 and a picture of the point 5 on a number line and someone told you to add them. Naturally, you would write 5 as a number first, because you don't have a useful way to add a number and a picture. But this doesn't change the results of adding the quantities 3 and 5; it's purely an artifact of the way the information was presented to you.

Re: Modern Language Wishlist

#43

Clojure and Scala are both there, except on idiomatic libraries (you might have to use Java libraries). Clojure wins on simplicity of syntax (Scala has a rule that operators ending with ':' associated to the right, which makes an incredible amount of sense once you understand the language but is annoying and arbitrary to beginners) and homoiconicity. Scala wins on pattern matching and robustness (static typing). I'd…

Because Clojure is a Lisp we have macros and with macros comes a lot of power. Clojure has a full powered pattern matching library. See this: https://github.com/clojure/core.match

Re: Modern Language Wishlist

#44
post #36

Earlier quoted context omitted.

I find it interesting that two of the most exciting languages that exist right now are built on top of the VM for one of the worst ones.

The strength of Java for many years has been the platform, and indeed the surrounding ecosystem, not the language. In that sense it's no surprise that there is a lot of effort going in to providing better languages on that platform.

The reason I'm not using Clojure is that it's based on the Java platform. I keep hearing that JVM is nice because there are good libraries, but I haven't figured out what the good libraries are. Sure, there are some nice platform independent abstractions for common operating system interfaces like file and network I/O, but it still lacks lots of stuff.

The problem with Java libraries w.r.t. modern high level languages is that Java libraries are built on Java abstractions. It doesn't matter how high level the new language is, but when interfacing with Java libs, you have to stick to single dispatch object oriented programming. So in the end, there are many cases where you use the Java library through some wrapper layer written in Clojure or your Clojure code ends up looking a lot like Java.

Once you add a wrapper layer shim between your preferred language and the platform, it doesn't matter what's underneath. That's why I like to stick to languages that are built on native code and libraries, C and Posix and Unix API's with some Linux and/or BSD additions. Of course, if you want to run on Windows, all the code has to be duplicated since Win API's are different.

Re: Modern Language Wishlist

#45
post #10

This just seems like an everything and the kitchen sink list. I am not convinced supporting every possible use case leads to an approachable/efficient language. It seems akin to arguing my car should also be a boat and an airplane.

How far is Python from this list? Macros are missing but the remaining list seem close to me.

Math sucks a lot in Python 2.7:

  3 / 2 == 1
Python 3 fixes that, thou, but still it uses floating point numbers instead of rational numbers.

Re: Modern Language Wishlist

#46
post #45
post #10

Earlier quoted context omitted.

How far is Python from this list? Macros are missing but the remaining list seem close to me.

Math sucks a lot in Python 2.7: 3 / 2 == 1 Python 3 fixes that, thou, but still it uses floating point numbers instead of rational numbers.

There "from __future__ import division" to fix that.

Re: Modern Language Wishlist

#47
post #31

Most languages have most of the listed features. The most interesting uncommon idea on that list to me is model of time. But only when it allows reversible computing. I don't know how practical that is though. Anyways I've separated out the parts of the list which I think are less common. And listed examples off the top of my head so by no means is the below meant to be exhaustive. The uncommon ones: * Units - F# and…

Great overview, thanks! I added some new stuff to my reading list. :-)

Just some notes from a Scala user:

Regarding Units: I bundled some work done before by other people into a nicer package/syntax, apart from a few missing bits working with Units looks quite nicely in Scala, even without any special support for it:

    val mass: Mass[Double] = 4.0 kg
    val longMass: Mass[Long] = mass asLong
    val length: Length[Int] = (5 m) * 3
    val time: Time[Int] = 1 s
    val doubleTime: Time[Int] = time + time
    val temp: Temperature[BigDecimal] = BigDecimal("22.22") k
    val speed: Speed[Int] = length / time
    val area: Area[Int] = length * length
    val volume: Volume[Int] = (23 m) * (1 m) * (1 m)
    val smallVolume: Volume[Double] = (volume asDouble) / 12.0
    val area2: Area[Int] = volume / (23 m)
    val accel: Acceleration[Double] = (10.0 m) / ((2.0 s) * (1.0 s))
    val accelNum: Double = accel toDouble
The type annotations are not needed, but helps undestanding the design.

Scala will very likely get macros in the next version, together with pluggable types/type providers. Macros not in a Lisp or "extend syntax" sense, but more in a Nemerle sense. Scala macros are written in fully statically typed Scala and are checked at compile time before and after expansion.

Re: Modern Language Wishlist

#49
+ 1 for easy serialization. Every language should have equivalent of Python pickle module.

Sometimes you need specific file format, compatibility between languages, customization, etc - then pickle is not enough. But for my uses pickle was good enough most of the time, and it's stupidly easy to use. No need to change your code in any way. That makes one-off cashing of intermediate results to file system manageable, implementing save/load game is 3 lines of code (counting import). I love it, and I miss it in every other language I use.

Javascript has JSON, but writing general code to serialize arbitrary object graph with cycles, functions as field values, properly storing prototype chains, etc is still hard.

Re: Modern Language Wishlist

#50

hmm, what exactly does he mean by data-oriented programming? iirc that's something where you don't store data chopped up into objects, but have arrays that keep all the data of one "aspect" of all "objects"... or something like that. something game programmers would use, helps avoid cache misses. is that what he was talking about? if so, what does it have to do with macros?

I meant data-driven programming.

http://www.faqs.org/docs/artu/ch09s01.html

More data (and data structures) and less code. It's very common in Lisps and other homo-iconic languages.

Post reply on HN