Slashdot Mirror
Is Ruby's Decline In Popularity Permanent? (computerworld.com.au)
An anonymous reader quotes Computerworld:
Ruby has had a reputation as a user-friendly language for building web applications. But its slippage in this month's RedMonk Programming Language Rankings has raised questions about where exactly the language stands among developers these days. The twice-yearly RedMonk index ranked Ruby at eighth, the lowest position ever for the language. "Swift and now Kotlin are the obvious choices for native mobile development. Go, Rust, and others are clearer modern choices for infrastructure," said RedMonk analyst Stephen O'Grady. "The web, meanwhile, where Ruby really made its mark with Rails, is now an aggressively competitive and crowded field." Although O'Grady noted that Ruby remains "tremendously popular," participants on sites such as Hacker News and Quora have increasingly questioned whether Ruby is dying. In the Redmonk rankings, Ruby peaked at fourth place in 2013, reinforcing the perception it is in decline, if a slow one.
What is Ruby?
Meanwhile, we grown-ups use Perl and C and laugh at the demise of this week's hipster language.
Now get off my lawn.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Hey kids here is a tip: Swift, Rust, whatever you are using now: they are just a fad. They are controlled typically by a single corporation. They won't last.
Ruby on Rails doesn't fit in as well with the new Javascript ecosystem. Compared to Node, it seems difficult to use.
That doesn't mean it will go away: it will probably adapt to the new Javascript frontend styles, and it was always complex next to PHP. As a language, Ruby is sweet with its DSL and it's harder to make type errors like you can in Python. I'll be honest, I'm not sure why Python is more popular.
"First they came for the slanderers and i said nothing."
Of course! All modern Full Stack Programmers (i.e. do everything Joes/Janes) must use Javascript on both server and client.
No Ruby on Rails for you...
As for shell scripting and toy programs that's what Python's for.
It's pretty clear that Python's going to come out on top of the GenY/Millenial coding club. Ruby got a quick lead making Web 2.0 development easy but Python hit critical mass just by the number of available packages. Numpy, Matplotlib, etc. "How to ___ with Python" nearly always turns up a result.
And peers: No, just like COBOL and FORTRAN, C and your current $favorite_language isn't ever going to go away. I still do a lot of C, Matlab and Simulink at work. But when I have the opportunity Python is just faster due to the shear number of packages that already exist.
Unless Ruby has something new to offer then it's popularity will continue to wane and other languages will continue to displace it.
Anons need not reply. Questions end with a question mark.
Yes.
The web fad moved on. They're never coming back. And good riddance.
Ruby will continue to grow in popularity for other types of uses.
On the contrary, every programmer should learn a new language every year. The catch is to ignore what employers think is trendy and pick one that will teach you something lasting and useful.
If you already know Haskell, try Coq. If you already know Smalltalk, try Erlang. And everyone should try writing 10k+ lines of Prolog some time.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Also, too, and neither, by not so old white, pole smokers.
Happiness in intelligent people is the rarest thing I know.
Ernest Hemingway
Once you acknowledge this fact, it pretty much explains everything.
I guess it is a culture thing again. ... I hate its syntax.
In Germany(Europe?) there is basically no demand for Ruby.
Luckily
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
There are actually not enough interesting languages so you can learn one per year.
I 'can prolog' but I never grasped how to solve a problem in Prolog without my programs looking like pascal.
I understand every prolog problem/solution I see, but simply don't grasp how to come from the problem to the solution.
I mean simple stuff like the wolf, sheep, salad problem. How to express that in Prolog I know, but how to come to that idea/solution I don't know,
I never saw a 10k line Prolog program by the way. The biggest I worked with (writing support code in C/C++) was about 1k or a little but more.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Techno Psychobitch bitch is utterly terrifying hipster superset of Erlang! The real Rockstar language.
Kids be cool use Erlang reborn as OTP
http://saveie6.com/
Another great solution looking for a problem to solve.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
As for shell scripting and toy programs that's what Python's for.
Why would someone use Python for shell scripting? If anything, that's one of the areas where it's the worst offender, with its retarded approaches to managing conflicting libraries (ex: virtualenv) and a blatant inability to handle character encoding properly. It doesn't even have a switch statement, which is a pretty common need for shell scripting, and the Pythonic way to handle command-line arguments (another staple of shell scripting) is more verbose than my chatty aunt when she's had too many drinks.
I'm not saying the language is not useful in some cases; it's somewhat intuitive and comes with powerful features, but the fact that it's a prime candidate for using Docker says a lot. Even PHP has a better model for conflicting libraries and less chances of causing carpal tunnel syndrome when you need command-line arguments.
If you're going to make shit up to look cool, at least pick a topic you're knowledgeable about.
lucm, indeed.
Puppet just hangs. It's not Windows-specific; it's a feature of this nightmarish system. I've seen cases of million+ queued jobs slowly murdering the masters. Maybe it works if one has 3 servers and 12 lines of config but in a real environment it's just a terrible system.
Take puppet to the backyard and shoot it in the head. Then bring in Ansible. No flaky agent, no constant chat on the network, no mysterious ordering of tasks, no need to find countless plugins written by random people to do the most simple of things. I've seen Ansible work smoothly on 2,500+ servers with fairly complex variations in configs and dynamic inventories.
I've never seen anything good written in ruby and puppet is just par for the course.
lucm, indeed.
As far as interpreted languages are concerned, Ruby is by far my favorite. I can code in that language far faster than any other, despite having decades more with the likes of C and C++. It’s nice for quick-and-dirty prototypes and things that don’t require a lot of processing power. But for serious tasks, it’s just too damn slow. I have tried, for instance, to write parsers in Ruby because its string and array manipulation are really convenient, but for most data sources, the Ruby programs just can’t keep up. And I’m no slouch at playing “golf” with intricate Ruby expressions. What’s worse is that with the global interpreter lock, I can’t get more throughput from threading.
I’m not a huge fan of Python in terms of syntax, but although general Python code is of comparable things, Python has some tools that make it invaluable. I’m thinking specifically of sympy and numpy. Simpy is an amazing symbolic algebra library. I can’t tell you how nice it is in machine learning to be able to have it automatically compute partial derivatives of arbitrarily complex expressions. And when you can organize your data into vectors and matrices, numpy can use GPUs to get incredible throughput. This is the only reason I bothered to learn Python, and it’s one reason Python is eating Ruby’s lunch.
Desired state configuration is a concept that doesn't survive contact with reality. It looks good on a whiteboard but that's about it.
When you look at it, you think: oh that's cool, it's decentralized. But it's only on paper. It's susceptible to all kinds of unexpected systemic effects, just like antivirus storms with "edge" protection systems, so to get it working properly, you have to inject rack awareness and all kinds of messy tweaks that take out all the benefits of being decentralized. Totally not worth it.
lucm, indeed.
http://click.pocoo.org/
Rails may be taking a back seat, but Chef is very much in use, and will be for some time to come.
~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
Erlangs little sister Elixir is making me cheat on Ruby behind her back and I think we are going to elope in the near future. Ruby is the sweetest thing and all, but Elixir? She just never stops.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
Maybe so but we still have all the money and that compensates for therest.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
Ruby is not a real gem as some people may think.
I have learned upon the situation and reached the following conclusions:
1. Ruby pollutes the program namespace because it introduced a program called "gem". Why couldn't they call it "ruby-gem"? I don't believe they deserve to take the names of two precious stones in the /usr/bin folder.
2. Ruby on rails always makes me think of a kidnapped girl called Ruby, which is strapped to the railroad, while shouting helplessly.
Because of these reasons, Ruby is on the decline. And nothing good will happen to Ruby until those problems are resolved.
Thanks.
hemi
Does implementing your own invented functional language in 10K+ of Prolog count? Even when it was in 1989 and the language is a pre-Haskell lazy pure language?
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
I prefer to delve deeper into the few languages I already know and use on a daily basis, and focus on mastering my craft with those particular tools. My feeling is that I'm better served by focusing on a few languages that I'll actually be using. As interesting as it may be to pick up Haskell or Prolog, I can't think of how I'd even want to use those languages in my current development efforts. I've got plenty of projects without inventing new ones simply for the sake of learning a language.
As for learning new languages, I do that as the need arises. I entered the workforce knowing Pascal and C/C++, and subsequently learned Lua, C#, Objective-C, HLSL, GLSL, Bash, and Python.
Irony: Agile development has too much intertia to be abandoned now.
Yes. You may now learn Agda.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
There are actually not enough interesting languages [...]
I strongly disagree. Netcraft will never confirm it, but a lot of interesting languages exist. You just need to avoid "yet another interchangeable block-structured language with a Simula-like broken object system", which sadly describes most of the popular ones.
I never saw a 10k line Prolog program by the way.
My point precisely. Prolog gets weird at that scale.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
I love how the tech world has nearly non stop crapped on PHP but largely left Ruby alone. While I haven't used PHP in about 8 years, I do admire the fact that most websites that use it and then grow massively, then continue to use it. While most Ruby sites that I know of dump Ruby on Rails as they cross a certain size and just can't keep it working.
I can't comment on why this is, just that I have seen it at least a dozen times on sites where the company was crossing about the 5 million in value barrier. The three complaints of the people running the companies are: Can't get truly senior programmers who will touch Ruby. Progress pretty much stops as they fight more and more with their product as performance and new functionality dries up. And usually someone within the company starts using a whole other platform to start redoing chunks of their product with results that make them angry they are so much better.
On one note, the definition of "Senior Programmer" is not someone with many years of Ruby experience, but huge amounts of experience with massive projects. The key to the definition is not just time in the business but a proven track record of putting multi million dollar projects to bed over and over. If they mention Ruby they get no interest from these types, if they don't mention Ruby then these types bugger off when they hear Ruby. But when the prospect of hiring them to replace the Ruby with a whole new foundation, they are usually very interested.
A decade ago, Ruby was hip, It is not hip, it is often an indicator of a site built by people who have never managed a site much bigger than a sub 1 million dollar company's web site (a company where the website is the company that is).
But like any halfway workable language. It seems to work fine for basic, data in and out on a website type drudgery. Thus it won't just die as there are no doubt many 30 year olds with a decade of Ruby under their belts who will insist on using their singular hammer for the rest of their careers. VB is still a thing too.
With an industry perspective like that, I can see why Ruby is on the Ropes.
Rails is the primetime tentpole project for Ruby and it's a hideous mess. And - unlike PHP - it's a mess that doesn't work. Yeah, Ruby itself is neat and well built and well designed and all that but the stack that includes Ruby barely works compared to other solutions.
LAMP (with P for PHP) OTOH just works. Install and fire up your LAMP stack, upload your PHP files via FTP, call the URL, works. End of story. Yes, PHP is a historically grown mess, but it get's the job done and it is a very well documented mess that offers solutions for any web problem you can think of. Contrary to such blowhard tools like Ruby/Rails that pisses it's pants when you've got some wrong minor version running and need an entire extra Node installation just to handle rollout and such.
If anything will replace PHP for serverside web, it will be JS/Node or something like that. And even that is still up for debate and will need a few years to show and tell. And will probably only be able to happen if microservices and vertical + horizontal scaling become a widespread need - which actually doesn't appear to be the case.
Ruby/Rails hippsters get lost in details while the PHP folks just roll out their Drupal and WordPress balls of hair within 5 minutes, slap on a few of the bazillion plugins available, do a little PHP-style sticky-tape and chickenwire coding and then go home with a happy customer and a web-project delivered on time.
Yeah, PHP/LAMP does quite a few things wrong, but until a new PL actually copies what it does right, it will remain king of the web hill. And for good reasons too.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
The comparison to COBOL is just plain vanilla ridiculous. COBOL conservation is not a property of language, it's a property of the domain that chose that language 50 years ago.
Nothing like this happened to any other languages.
I do not believe in karma. "Funny"=-6. Do good and forbid evil. Yours, Oft-Offtopic Flamebaiting Troll.
When I can make the choice myself, I use bash for scripting and Java for anything larger/more complex.
Do you think somebody who already master bash should learn pocoo unless he has to patch something already written in it?
Everything I write is lies, read between the lines.
Ruby is fantastic for writing a-lot of code quickly. But it has terrible performance, and is has terrible maintainability characteristics (I recall doing global file system searches to find the file that defines something that my code requires, which is brought in by another require, and then another).
Performance sometimes matters. If one's app requires 20 VMs in Ruby, but only 2 VMs in Go or C++, then the cost difference can be substantial.
Also, Ruby - while 20 years old - is surprisingly immature. E.g., a few years back, I wrote a multi-threaded program in Ruby. It didn't work. After days of scratching my head, I discovered that while Ruby used native threads, it had a global interpreter lock, forcing the native threads to take turns. Maybe they have fixed this by now. My program needed true concurrency, so I had to re-write it using processes. Gosh - Java got threads working after the first two years.
Firms that really know how to maintain large codebases have also discovered that type-safe languages are very effective for maintainability. Check out this post: https://medium.freecodecamp.or... . I myself have experienced this: I once translated a fairly good sized codebase from Ruby to Java, and in the process discovered a large number of potential bugs - thanks to Java's type safety. I have found that when I refactor Java code, I introduce zero new bugs, but when changing Ruby code, the only thing that prevents new bugs is a large suite of unit tests. Thus, writing in Ruby _requires_ that one write comprehensive unit tests. I personally don't use TDD - I use ATDD, so my focus is on acceptance tests, not unit tests. Ruby _forces_ me to write unit tests. I don't want to be forced to work a certain way.
I am not bashing Ruby - I think it is great for some things - but people (like those at Google) have come to understand its shortcomings.
Nowadays I don't have enough time for this, so anything new I learn is on a "need to know" basis.
Everything I write is lies, read between the lines.
There are actually not enough interesting languages so you can learn one per year.
I 'can prolog' but I never grasped how to solve a problem in Prolog without my programs looking like pascal.
Strange, you must be using a different version of Prolog than I used to because, in the version I used, it was pretty hard to write a program looking like a pascal one.
I understand every prolog problem/solution I see, but simply don't grasp how to come from the problem to the solution.
In the version I used, every problem was pretty much solved with recursion.
I mean simple stuff like the wolf, sheep, salad problem. How to express that in Prolog I know, but how to come to that idea/solution I don't know,
I never saw a 10k line Prolog program by the way. The biggest I worked with (writing support code in C/C++) was about 1k or a little but more.
Yep, recursive programs are typically small.
Everything I write is lies, read between the lines.
Mostly because between the two you can make a single app that works on mobile, tablet & desktop.
Any framework + bootstrap pretty much does that.
Everything I write is lies, read between the lines.
Pocoo is a team that develops several popular Python libraries, so you wouldn't learn Pocoo per se. The use case for the Click library, linked above, is when you need a good quality CLI for a Python program. Usually that's going to be adding CLI functionality to existing code, or replacing an old home-rolled CLI with something that sucks less.
But as for your question - the answer depends where you are in life. Unfortunately there are very steeply diminishing monetary returns for learning new languages if you're an experienced programmer. Otoh, 2 languages isn't much, so feel free to learn a few more before you get burnt out. Kotlin would be at the top of my list today, and for a person already in the JVM ecosystem background it's an obvious choice.
As someone who wrote an enterprise application using AngularJS for 5-years - the original one was great. I haven't checked recently but v2 was a flaming pile of garbage that didn't properly work. I also would expect people to be a lot more cautious about adopting v2, users writing real applications don't have the luxury of re-writing the entire UI every couple years.
What would be your go-to language+framework if you wanted to build a web application + restful API that needed an ORM layer to an RDBMS? This is an honest question; I don't ask rhetorically in order to imply that RoR is still the best option. Just curious what people think is the best option in 2017 for this type of project.
Wait... so we're mixing client-side and server-side now?
If you Don't Repeat Yourself, you have to write your server-side application logic in JavaScript (or in a language that compiles to JavaScript) so that your app can use provably the same logic for prevalidation on the client that it uses for authoritative validation on the server.
I can't stand Ruby and gems because updates to things are so fragile. We're dependent on a lot of libraries (through dependencies of dependencies) and if any one of them is not THE version it is supposed to be, everything breaks. Fortunately this is just our build tools (the app is using an older version of SproutCore). If it was deployment on production, we'd be totally screwed because we'd never be able to upgrade anything and would be vulnerable to security issues constantly.
NPM/node runs that same risk (the second i saw there was an "nvm" available, I knew things were going downhill), but the idea of dockers is a better way to protect one application and its version dependencies from another.
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
Strange, you must be using a different version of Prolog than I used to because, in the version I used, it was pretty hard to write a program looking like a pascal one.
With "Pascal" I mean: the rules more or less worked like procedures and not like rules.
In the version I used, every problem was pretty much solved with recursion. ;D
Well, that indicates that you probably did not really use logic/rule based programming, just like me
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Well in my resume, I have about 30 programming languages listed, that I actually have used in commercial software development.
As long as there are no new languages with new concepts, or better syntax for old concepts, I don't see anything interesting on the horizon.
I mean: I could learn CoffeeScript ... but for what? I only use JavaScrip in an HyperCard clone called NovoCard (for iPads) ... I don't really like web development.
If I was to really learn something it would probably a library like AngularJS or ProcessingJS.
I still have not done real SmallTalk though ... that would be fun :D
However if you have suggestions, I'm full ear (german saying, sounds stupid in english)
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
What about writing a 10k Prolog implementation instead? Given the limitations of Prolog, maybe that would be much more useful for an individual.
Ezekiel 23:20
Here's the complete Python 3.5+ example:
Each of these things that doesn't appear in your Ruby snippet has a reason to exist:
shell=True Defaulting to not using the shell means defaulting to immunity to shell injection vulnerabilities. Python has a bit more culture of being safe by default than, say, PHP. It also means defaulting to not being quite as dependent on which shell the user prefers for interactive work, particularly on operating systems from traditions other than POSIX. encoding="utf-8" Standard output from this pipeline is a stream of bytes. Not all characters in filenames fit in one byte, and not all pipelines even produce bytes that should be interpreted as characters. This tells Python that the standard output should be decoded as characters. stdout=PIPE).stdout Sometimes you want to capture standard output and standard error; sometimes you want to let one or both pass through.constructor: notice no stupid __double_underscores__
So how do you provide both and a method called initialize? If you actually want a method called initialize, such as if you are wrapping an underlying interface containing a method called initialize, do you have to spell it instead as something like initialize_?
lack of proper string interpolation makes this clunky and tedious
How else would you go about specifying a format string in a context that differs from the context that includes the local variables, such as reading the format string from a file that lists the translations of format strings into your user's native language?
Nobody should use Windows for servers and those that do shouldn't need to program anything because it's just to run closed source software. If you want to program, do it on a proper server, there is no need to hang it in Windows-space just for the heck of it.
Custom electronics and digital signage for your business: www.evcircuits.com
That's the problem of pretty much any JS framework except maybe some of the staples like jQuery (and even there they often kick out working code). I've worked with many a framework of CSS/HTML/JS and they all suffer from the same problem, upgrading the framework results in your program being completely useless.
Custom electronics and digital signage for your business: www.evcircuits.com
& desktop.
This is laughable at best. node desktop applications may in fact be worse than java desktop applications.
When the rise and fall of the Ruby empire is written, Chef will probably have a part in both stages. Ruby is more a victim there, but some of my most frustrating encounters with Ruby have involved Chef. Sticking to Ruby earned Chef favour from developers but Puppet's custom DSL choice was the right one. Using Ruby forces hard dependencies where everything ends up being dependent on 'windows' and 'yum' and 'apt'.
A major problem with the first era of config management / DevOps was too much code that does too little. Instead of telling Chef via an abstraction to enable the apache service, you have to write:
And this is one of the better written actively maintained cookbooks.
Then there is the annoyingly common convention where every time there is a new release of the underlying package, you have to update a hash in the Chef code and release a new version of the Chef cookbook, which of course is delayed - looking at you Elasticsearch.
It runs 'yum install elasticsearch' which installs a signed package from the repository. But the first law of config management is 'support everything and let the lowest common denominator dictate design'. So supporting whichever crappy OS / release that does not have native packages always takes priority over writing something that just works and will continue to just work.
e.g. The Chef yum provider can't handle obsolete package versions. If you tell Chef to install somepackage-x.y.1, and that version has been obsoleted by somepackage-x.y.2, somepackage-x.y.2 gets installed while Chef thinks it installed somepackage-x.y.1. The next time you run Chef with exactly the same config, it will fail because of the implicit downgrade.
Which brings us to the Third law of config management: Idempotence in config management is like world peace for the U.N. - promising an idealized unachievable goal confers nobility and thus failing at it all the time is ok.
Ruby isn't the culprit here but it is the enabler. Manual dependency management means no one configures versioned cookbook dependencies. So your infrastructure is code defined, but what that code is is a spur of the moment thing as Chef fetches the freshest stuff off supermarket.chef.io. Bringing us to the second law 'it mostly works' is good enough.
In the world of clustered distributed multi-node services, the much praised Kitchen test framework can't test multi node deployments. Have a two-node Elasticsearch cluster - forget writing tests, and add a bunch of timeout hacks to handle asynchronous builds. Let's have a long existential discussion over whether multi-node testing is really needed and continue to write tests for whether "package 'ap
Having supported chef in a large enterprise production environment, I have to wholeheartedly agree with all the points you made.
Looks like I will be focusing less on Ruby / Chef and more on AWS / Python.
~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
Comment removed based on user account deletion
Yes, Ruby is a very slow language. Apparently Crystal hopes to fix that. However, if nothing else it has a very fluent syntax, and the comparison with VB is just spiteful. Rails may deserve more of that type of venom, but even it has its place. Ruby can be used pretty well for simple scripts and for prototyping, and for anything that receives a trivial amount of web traffic.
PHP has come a long way to achieve respectability, considering that it took some years before it acquired the concept of classes. It's a very fast scripting language with relatively familiar ALGOL-style syntax, if a bit verbose. It's not quite as boring as Java, but the real problem is that there are a zillion people in third world countries that churn out far too much PHP code.
I started in PHP and fell in love with Ruby. I'm not particularly concerned if it's going to be useful on the day-to-day. Crystal might be a thing, or Elixir, but probably I'll end up learning Haskell and Go and then hoping that their Ruby-influenced relatives are an option. Note that your definition of 'Senior Programmer' is one I'm not particularly interested in. I mean, it might even be a good one, I just have more interest in exploring languages and environments than building something that large. Hopefully there's money in that.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
After the 20th language or so, it gets easier. I'm somewhere in the early 70s at the moment. Lost count a while ago.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
As long as there are no new languages with new concepts, or better syntax for old concepts, I don't see anything interesting on the horizon.
Like I said, you have to avoid all the broken Simula clones. Pretty much every popular language is one of those. (Although to be fair, some languages are nice if you avoid most of their object system. I'm looking at you, C++.)
So the first thing I'd do is complete the list of interesting features if you haven't already. So, for example, if you have never used a constraint logic language (e.g. a modern Prolog with some CLP extension), go do that. Or if you've never used a language with a logic-based type system (e.g. Haskell), go do that. Once you've covered the basics that you may have missed, look for the interesting embedded languages (do you really know PostScript?) or research languages.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
That are actually 3 bad examples :D
PostScript is pointless, and as far as I understand it a variation of Forth.
Prolog is my anathema, because I don't grasp how to convert a problem into a simple prolog program. It seems extremely hard to teach. I mean: the examples are always super easy and simple to understand. But given a simple problem, how to express it in Prolog is beyond me. It seems no one ever understands the questions I'm asking. (Yes, I can program in Prolog, but my programs don't look like typical perfect Prolog solutions)
Haskell I was forced to use/learn in 4th semester at my university. It is probably the only one on your list that is worth a try. But at that time I found it completely incomprehensible, just like modern PERL.
or research languages ...
I do that all the time, but only read the papers
The functional part of Haskel is actually not that challenging, with lambdas we have that in Java (somewhat) too, we have it in Scala and in Groovy. But the weird syntax is annoying, but that again is the same for Scala.
Interesting languages are Io and Loke e.g. But well, I have no pet project that is suited to play with them.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
That are actually 3 bad examples :D
Haha.
PostScript is pointless, and as far as I understand it a variation of Forth.
Closer to Logo, probably. But some day, you may have to generate PostScript...
Prolog is my anathema, because I don't grasp how to convert a problem into a simple prolog program.
OK, so how about a modern variant such as Mercury? Mercury is easier to use as if it were an imperative language, and then you can add nondeterministic (or semideterministic) bits as needed.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Interesting :) thanx.
Not sure I finally understand how to craft the required clauses forr e.g. the wolf, sheep salad problem. But on the first glance the language looks interesting. And a build in 'rule system' or logic language certainly is worth a try.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
PyPy closes file handles properly. The problem is that some programs make invalid assumptions about how file closing works in Python. The Python documentation explicitly says that ref-counting semantics are not guaranteed by the language: expecting file handles to be automatically closed immediately at the end of a scope is incorrect, though it happens to "work" in most versions of the CPython interpreter.
If the timing of when file handles are closed is important, you should use a with statement or otherwise ensure that close() is called at the proper time.
rage, rage against the dying of the light