It's kind of sad to watch Scheme, Python, and Perl self-destruct (and a pleasure to watch C++ go), but that doesn't mean we can't look forward to the future. What will take their place? Whose pet language will achieve widespread prominence? Perhaps Lisp will shake off the AI winter, or programmers will realize the value Haskell's Abstract Bullshite has. Or could it be something new?
I'd like to see something completely new. Not just a new language with a bunch of new tricks, but a completely new paradigm. I don't think this will happen until a ways into the future, perhaps when the computing world undergoes some kind of radical transformation somehow.
</my bullshit speculation>
Name:
Anonymous2010-01-21 22:47
Why would you want to ruin a toy language with "widespread prominence?" That only leads to the kind of streamlining that makes it more "accessible" to a broader range of users ("dumb down").
>>5
I was actually thinking something to do with parallel computing and where the computing world is headed in terms of that, but I think the ideas I have in my head might be really dumb so I will say no more. I don't know much about the terms you listed.
>>1 It's kind of sad to watch Scheme, Python, and Perl self-destruct (and a pleasure to watch C++ go), but that doesn't mean we can't look forward to the future.
In what way are they self-destructing? I see these languages are still widely used by their usebases, and I don't see them going away. Scheme is widely used in the academia, and used in some commercial contexts, it has many implementations, though I expect it will have less R6Rs ones. Python is doing pretty well in the 'plumber' usergroups, and has many libraries, same goes for Perl, albeit it's used for slightly different purposes. C++ is still widely used in the commercial world, but not as much for things were a slower, but easier to use language would do (C#/Java). Perhaps Lisp will shake off the AI winter or programmers will realize the value Haskell's Abstract Bullshite has.
There's quite a few actively developed implementations, there's many libraries and a decent userbase. Lispers don't really care for their language to become mainstream(same could be said about Haskell), but they'll gladly write code for themselves and publish nice libraries. In practice, you can do anything you can do in mainstream languages in them, and much more. >>3 I'd like to see something completely new. Not just a new language with a bunch of new tricks, but a completely new paradigm. I don't think this will happen until a ways into the future, perhaps when the computing world undergoes some kind of radical transformation somehow.
New ideas and paradigms are being developed, but I think we already explored the main ones. Some problems are still tricky/hard, such as parallel processing, and they need to be solved as that's where the hardware is going. If quantum computing ever becomes practical, there may be some new paradigms that will be used to make it more accessible, but I don't think it'll be too soon. >>4 Why would you want to ruin a toy language with "widespread prominence?" That only leads to the kind of streamlining that makes it more "accessible" to a broader range of users ("dumb down").
It's perfect when the userbase is mostly made of experienced users, and they maintain the language and libraries for themselves. Too small a userbase can lead to "death", or having the language become forgotten to everyone. Too big of an userbase can lead to other kinds of problems, such as legacy support and being stuck with initial hacks because people don't want to break code. Dumbing down can be dangerous, but if that happens, then it just becomes a different language. >>5
Why do you need a new language for that? Dataflow can be incorporated into existing languages which are powerful enough without even having to change the language at all.
Name:
Anonymous2010-01-22 0:12
>>8 In what way are they self-destructing?
Scheme is fragmenting. Apparently now one standard isn't enough, so they're going to have one that wants to be CL. This can't end well. Python 3.0 versus 2.6 (or whatever it is) is a fiasco. Perl 6 is DNFing as we speak. C++ is just gradually losing ground to languages that are actually appropriate to the domains it was used in, with Sepplesox as a desperate grasp at relevance.
There's quite a few actively developed implementations, there's many libraries and a decent userbase. Lispers don't really care for their language to become mainstream (same could be said about Haskell), but they'll gladly write code for themselves and publish nice libraries.
It's not mainstream like Perl was. And I think most Lispers, though they may babble about secret weapons, would love to see a shelf full of Lisp books in the store and library, and to have their pick of Lisp jobs. Maybe Haskellers too, although it seems currently to be a more popular academic vehicle than Lisp, so they might be perfectly happy just doing research with it.
Besides parallelism I see two areas that may be underserved;
Firstly, while there is a general trend towards abstraction, encapsulation and reusability, object orientation being a step forward in that regards, I think there's still a lot of poorly explored areas in reusability and interoperability. Large projects end up containing a lot of highly specific glue code. The silver bullet problem is in play here, but there's likely to exist some novel way of seeing things that can make software components more component-y and 'effortlessly' connectable.
Secondly, computers are endemic, but programming skills aren't. Some people spend hours a day on doing 'very small shell script' jobs without ever realizing it. A very general tool that allowed people to quickly automate specific automatable computing tasks they encountered in a way that fit well with the thought process of the vast majority of non-programmer brains could become really popular.
If anyone here were to see a solution to any of those, they'd probably just ask why anyone would want that. Maybe it's not something we would think deserved to be called programming at all. Which is why they're inadequately/ineptly explored.
Probably someone will come up with something really smart, only young programmers will use it, and we'll end up sitting around like the old coots that still think structured programming is just a fad, and who can't handle object orientation at all because they don't understand the concept. :(
Scheme is fragmenting. Apparently now one standard isn't enough, so they're going to have one that wants to be CL. This can't end well. Python 3.0 versus 2.6 (or whatever it is) is a fiasco. Perl 6 is DNFing as we speak. C++ is just gradually losing ground to languages that are actually appropriate to the domains it was used in, with Sepplesox as a desperate grasp at relevance.
Just treat them as different languages. Scheme R5RS != Scheme R6RS, Python 3.0 != Python 2.6, Perl 5 != Perl 6, C++ != Sepplesox. Just because they share a name, does not mean they're the same language. One may be derived from the other, but they're different. The old userbase doesn't go away as easily. And I think most Lispers, though they may babble about secret weapons, would love to see a shelf full of Lisp books in the store and library, and to have their pick of Lisp jobs. Maybe Haskellers too, although it seems currently to be a more popular academic vehicle than Lisp, so they might be perfectly happy just doing research with it.
While I wouldn't mind more Lisp books, most of the Lisp books that were released are of very high quality as only authors which truly had something to write wrote them. There may not be that many of them, but at least they're good. I can't say the same about the huge amount of ASP.NET, PHP, C#, ... books. The market does demand more books for popular languages, but that doesn't mean you'll get more quality books that you'll want to read. Lisp jobs? Some could be fun (and there's a few places that do hire lispers these days), but if Lisp becomes too mainsteam, the number of inexperienced programmers writing in it would increase too and one could imagine being hired to maintain some monstrousity that was developed by some inexperienced team, especially given how easy it is to redefine syntax and semantics in Lisp. Maybe I shouldn't worry about such things, but I've seen some scary code I've had to maintain written in lesser languages like PHP, and it wasn't pretty at all. Writing maintainable Lisp or Haskell code requires discipline, but the same could be said of other languages more or less.
Name:
Anonymous2010-01-22 1:24
>>11 Just treat them as different languages. Scheme R5RS != Scheme R6RS, Python 3.0 != Python 2.6, Perl 5 != Perl 6, C++ != Sepplesox.
Sepplesox is C++. Other than that, what you say is true, but dubious new versions are problematic whether you consider them the same language or not. They're intended to be successors. What happens when the new guy doesn't catch on? The old user base won't go away, but that doesn't mean a language is still vital (people still use APL and Smalltalk, for crying out loud). Do the devs say, "Okay, forget about all that stuff; we're going back to the old version"?
The market does demand more books for popular languages, but that doesn't mean you'll get more quality books that you'll want to read.
I'm not referring to books qua books, but rather as an indicator that the language is oft-used and popular. I doubt any Lisper would feel anything but good finding a rack of Lisp books in the store. They might suck, but: Holy shit, they're talking about my language! Regular people! Warm fuzzies everywhere.
if Lisp becomes too mainsteam, the number of inexperienced programmers writing in it would increase too and one could imagine being hired to maintain some monstrousity that was developed by some inexperienced team
Yeah, but would you rather have a shitty job working in a language you like, or in one you hate? Unless there's some kind of bias towards shitty workplaces adopting Lisp, the number of good jobs would swell with the number of bad ones anyway.
people still use APL and Smalltalk, for crying out loud
APL and Smalltalk aren't bad languages
I doubt any Lisper would feel anything but good finding a rack of Lisp books in the store
I would die of shock, or presume that I was dreaming, but that's because every bookshop near me is shit.
Name:
Anonymous2010-01-22 9:10
>>13
I love you! I love your language!I RNRS'D IT SIX TIMES! Keep revising!
Name:
Anonymous2010-01-22 16:12
>>15 APL and Smalltalk aren't bad languages
They're quite nice, yes. Sometime I want to make a 1kB roguelike in APL and see just how far that gets a person.
Name:
Anonymous2010-01-22 16:34
Would you guys really want to find books like "Learn Lisp Macros in 3 weeks!" or "Monads for dummies!"?
Maybe I'm a bad person, but I kind of like to know that some languages are beyond the capabilities of a web developer who uses PHP.
One can learn R5RS Scheme in less than 24h if one has some idea of Lisp(s). The document is less than 60 pages and is fairly easy to digest, especially if you have an implementation to play with.
Name:
Anonymous2010-01-22 18:31
I've read so much shit about monads, I've convinced myself that they are only particularly helpful in a pure language. I may be wrong about this, but whenever I look at scheme implementations of monadic operations I invariably ask myself, "Isn't this like tying one arm behind my back in a street fight under the silly notion that whatever doesn't kill me, makes me stronger?" Then I answer myself, "Yes, yes it is," and move on with my life.
haskeller: it carries on operations on the side. In order!
everyone else: um, wow, some feature
Name:
Anonymous2010-01-22 18:33
>>24
Somebody posted a monad implementation for CL on c.l.l a day or two ago. Apparently several people there have found monads useful in the past.
Name:
Anonymous2010-01-22 18:39
>>25
I'm not saying they're not useful, they definitely are, in the specific circumstance that the language that brought them to the fore has forced to be necessary. There's an interesting example of automatically tagging trees with numbers that was done in Haskell and Scheme from usenet or some shit. Kind of interesting, but I've not grokked it enough to see how it impacts 99% of programming tasks in languages that aren't Haskell.
>>23
I have the spec in my hand, it's 50 pages long and if we ignore the boilerplate(index etc.) and the formal semantics, you can claim that it is only ~35 pages.
>>24
You've probably written monads before, just under a different guise. You should read sigfpe's "You could have invented monads", it cleared it up for me.
>>25
I've had cl-monad-macros.lisp open in Emacs all day today, ever since that post. >>24
They're very useful in Haskell and ML-likes, but I think their benefit is deminished in stateful, non-lazy languages. I have no trouble straightforwardly translating most monadic code into stateful code in Lisps and other eagerly evaluated, non-pure languages. Monads do offer interesting abstractions and ways to reason about certain things, so some people may prefer their style to directly using side-effects. Other features like lazyness of continuations may be translatable directly to more 'normal' constructs, but that doesn't deny that they are able to represent certain problems in a more clear, elegant way than the code which directly implements it. For example, I think most people will agree that in languages which support maps and lambdas, mapping over a list, vector or some general sequence is nicer conceptually than iterating over it and building a new list, vector, sequence by hand (or possibly overwriting the old one?) - in some cases if you wrote the implementation directly, you may have to change more code, but if you used maps, you could just change some mapcar to a map or map-into, depending on your true intentions, without having to bother changing the underlying code which transforms each element.
>>28 They're very useful in Haskell and ML-likes, but I think their benefit is deminished in stateful, non-lazy languages.
I don't have a referenceto hand, but I've seen some posts circa 2004 on comp.lang.functional that seem to confirm this.
>>30 Want to get started with ANI programming right away? Head over straight to the ANI Tutorial.
Sounds like something /prog/ would be interested in.
Name:
Anonymous2010-01-23 3:11
>>30
anic isn't "impressive". There's barely half a parser (not even a hint of code generation!), yet the author makes it look like he's got a working, faster-than-C dataflow language.
Reading the author's posts it's quite clear that this is going nowhere, fast. He spends his time talking about syntax, cross-compilation, REPL, etc. and he doesn't even have a basic language spec or a clear explanation of what a compiled program will look like. His usage of buzzwords is second to none: "high-performance, statically-safe, implicitly parallel, general-purpose dataflow programming language", "zero-overhead dynamic code injection" (what the hell?), "jit-schedule in usermode"...