Hacker News Reader

Comment by StavrosK | Hacker News Reader

I just realized something: The time investment in learning a programming language is so large, that when faced with the challenge of writing something that your language is not suited for, you set about in an effort to make the language you already know fit what you want to do, rather than learning a new language.

This leads to things like desktop apps in node.js (or server apps in node.js, amirite), or high-performance apps in Python/Ruby, or mobile apps in PHP. Given this trend, a language that is very easy to learn/teach will soon take over everything, and, if Pyret is that language, brace yourselves for the oncoming "put Pyret in all the things" revolution.

View on HN

Of course you can butcher the language in all uses-cases it's not suited for but hopefully you realize that sooner than later. A complex language(e.g c++) would put off most of the students(unless they are CS students). It seems the language is heavely trading large scale development features for its specific use case(see the comment about unit testing below) so hopefully it will become "impossible" to misuse it.

This reminds me of observations on the rise of nationalism.

Once newspapers became large scale phenomena and states began building large bureaucracies, the reality that most people in most areas will only learn one (natural) language became a very unifying (and dividing) dynamic.

Computer science education idealists imagine a world built by the best students, those who finish the entire course of study they set out. It indeed seems logic that the world is shaped by the great mass of people who at the minimum useful level.

A large part of learning the language is learning the API. Is it possible to build a single common API ?

No. I think the best illustration is the continuation-based Web programming work we did several years ago: http://cs.brown.edu/~sk/Publications/Papers/Published/khmgpf... If you don't have the right underlying language (in this case, with continuations), you _can't_ have a similar API. Similarly, the reactive APIs we had in Flapjax [http://cs.brown.edu/~sk/Publications/Papers/Published/mgbcgb...] enabled entirely new kinds of primitive “library” operations; see, for instance, the drag-and-drop example in that paper.

The reason why some languages are more suited for some things than others is due to paradigms like callbacks in JS that were fit to certain applications (the web in this case). Python is incorporating newer "paradigms" like asyncio into its language, but it feels convoluted at this point. The preference of certain semantics for different application types brings forth the same problem (convolution) if we tried to implement a single API that fits all purposes.

At most you can have similar name conventions (e.g. strings.Contains, or Replace etc) but even so some languages use camelCase others dashes etc

So why aren't we all programming in Basic right now? It was supposed to be a simple programming language understandable by everyone.

You are being rhetorical, but over its long history dialects of BASIC have been used to write a huge amount of software. It was the first generally accessible interpreted language, and its influence on programming today is no less than Lisp or Smalltalk. It was a major driver of early personal computing, got Microsoft rolling, and in the process produced a huge crop of programmers that allowed the web to be commercialized and become what it is today.

You make it sound like it was an ill-conceived goal to make a simple and understandable language, but the reason most of us aren't writing our CRUD apps in BASIC isn't that we all moved to APL.

Certainly simplicity and understandability are very important language traits, but if you only concentrate on them, your language won't fit certain tasks well and won't get used for them.

Programming languages as Basic or Pyret certainly have their place and can empower people that didn't program before, but they won't take over the world.

i am eagerly awaiting a good linux command line implementation, at which point i will embrace the "put pyret in all the things" revolution. it's a beautifully designed language.

Thanks. This is where our “education first” emphasis comes in. I'd like that too, but it's just not our most critical need. Since it can be run on top of Node from a shell, what it mainly lacks is a REPL. One of our students took a shot at that and had half an implementation, but didn't finish it. So for someone interested in hacking on that, there is a starting point, and a REPL atop Node would a big win. I'd use it every day (-:.

it's not the lack of a repl I mind so much as the startup time. I'd love to be able to write small command line apps in pyret but the execution delay is painful. (that said, I fully appreciate the focus on education; there are lots of other scripting languages I can use!)

I agree! We're acutely conscious of it. This is precisely where, as you note, the education focus puts our resources elsewhere. Once those things settle down, this is something we're going to want very much even for ourselves.

I find learning a language (syntax, constructions) easy. What is hard, is learning its ecosystem, good practices, gotchas.

In this sense, a totally new framework / ecosystem for a known language is as difficult as learning a new one.

There's no reason you can't write high-performance apps in Python, unless you have decided to tie your hand behind your back and not use any of the optimization strategies which have been developed in the decades that Python has existed.

If you mean something like programming without using the heap, most high-level languages cannot do that anyway.

Optimizing Python generally means using numpy, cython, or the C FFI. Or numba. Or theano. Or pypy. Unless you farm out what you're doing to another code generator or compiled library, Python can't be made fast. Try making matrix multiplication fast without passing through the FFI at all in cpython.

Eh, sure, you can use something like Cython, but Erlang is going to have an easier time being fast and reliable, for example.

Reply on news.ycombinator.com