Can Ruby Survive Another 25 Years? (techradar.com)

TechRadar marked the 25th anniversary of the Ruby programming language by writing "there are still questions over whether it can survive another 25 years." The popularity of the Ruby language has been bolstered for many years by the success of the Ruby on Rails (RoR) web application framework which dominated the web scene, particularly among startups who wanted something that deal with much of the heavy lifting... But RoR, although popular, isn't the superstar that it was and It has faced fierce competition as issues such as scaling have become a greater concern for web companies. The JavaScript framework Node.js, for instance, has become popular as it requires less memory to deal with numerous connections because of its callback functions...

To improve performance further Ruby is introducing JIT (Just-In-Time) technology, which is already used by JVM and other languages. "We've created a prototype of this JIT compiler so that this year, probably on Christmas Day, Ruby 2.6 will be released," Matz confirmed. You can try the initial implementation of the MJIT compiler in the 2.6 preview1... Probably the clearest overview explanation of how MJIT works is supplied by Shannon Skipper: "With MJIT, certain Ruby YARV instructions are converted to C code and put into a .c file, which is compiled by GCC or Clang into a .so dynamic library file. The RubyVM can then use that cached, precompiled native code from the dynamic library the next time the RubyVM sees that same YARV instruction.
Ruby creator Yukihiro Matsumoto says Ruby 3.0 "has a goal of being three times faster than Ruby 2.0," and TechRadar reports that it's obvious that Matsumoto "will do anything he can to enable Ruby to survive and thrive..."

And in addition, "he's thoroughly enjoying himself doing what he does... and his outlook is quite simple: Programming is fun, he's had fun for the last 25 years making Ruby, and at the age of 52 now, he hopes that he'll get to spend the next 25 years having as much fun working on the language he dreamt up and wrote down in -- a now lost -- notebook, at the age of 17."

"We want Ruby to be the language that is around for a long time and people still use," Matsumoto tells another interviewer, "not the one people used to use."

Comments

Never thought I would hear about Legacy Ruby

[Billly Gates]

But fads go in and out. Meanwhile COBOL I heard is still popular in older enterprises. Will node.js and Rust have the same fate 10 years from now? Java seems to be declining but still is active on older software projects.

Re:Never thought I would hear about Legacy Ruby

[Anonymous Coward]

I don't think it's the case that COBOL is popular in old systems as much as nobody dares to update the COBOL in old critical financial systems.

Re:Never thought I would hear about Legacy Ruby

[bluelip]

Stick with C and COBOL. They're not fancy. They're not 'hip'. They're still here because they're rock solid.

Re:Never thought I would hear about Legacy Ruby

[Bruce Perens]

I once interviewed a programming candidate, sent to me by a recruiter, who had only programmed in JOVIAL for his whole career and only wanted to program in JOVIAL for the rest of his career. I guess my business didn't matter much to that recruiter.

Most of the really good programmers can learn a new language on the plane to their new gig.

Re:Never thought I would hear about Legacy Ruby

[LostMyBeaver]

I agree with COBOL, but C isn't solid... never has been. It's simple, stupid, and highly available. These are three important features in a system level language.

C should never be used for complex systems. It promotes insecure code by design. It simply works everywhere and if you wanted to make a new C compiler and the Linux kernel wasn't your goal, it's easy.

Never confuse available with solid. Modern computing is a cesspool of shit code in dangerous places because of "We code everything in C!". Redox is the first major effort to try and fix this. It will fail, but if we're lucky, Google will rewrite Fuschia in something better. Fuschia is already a boiling pot of bad code... much because C is a BAD idea for operating systems.

Re:Never thought I would hear about Legacy Ruby

[Anonymous Coward]

C lets you do what you want. If you want to program insecure code, it will let you. Your problem is with bad programmers, not programming languages. Constant coddling does not end with better results. Soon you'll have programmers writing code with children's building blocks and crayons.

Re: Never thought I would hear about Legacy Ruby

[Anonymous Coward]

So Ruby is trying to be like Java?

Re: Never thought I would hear about Legacy Ruby

[tigersha]

They might learn the language on the plane, sort of, but ghe whole standard library of most modern languages? No way.

Re: Never thought I would hear about Legacy Ruby

[q_e_t]

I'd agree with the siblings that recruiters tend to require significant AND recent experience in the particular programming language asked for. For example, I was once told that because I hadn't used a particular language professionally for two years, then they considered me to not be appointable, despite 15 years of previous experience with it. Adaptability doesn't seem to be valued. Mind you, they also wanted to give them a timescale for a project despite me indicating that a short feasibility study would be required, and that to ask for a breakdown with insufficient information was unreasonable.

Re: Never thought I would hear about Legacy Ruby

[q_e_t]

One of the problems with C is that it gives bad programmers enough rope to hang themselves, and anyone else nearby. It also allows any programmer who was careless at 5pm on a Friday that much rope, or one who assumed a library was secure and correct C is fast, but the issues outlined above mean that failure has a large number of entry points, which makes it harder for processes (code review and various levels of testing) to police issues. With a language that is safer by design then provided the compilation process is dependable, it should be safer, and the compilation process should be more tested through use. Languages that are safer by design are no panacea, and there can be issues with efficiency of the code, though. And even with that, formal proof that the code encodes the specification is rarely done. Even with code that is correct, the specification (if it even formally exists) may not be, and modern systems are made from numerous components, and the architecture may be incorrect.

Re: Never thought I would hear about Legacy Ruby

[AuMatar]

You don't need to. Nobody knows the whole standard library of any language now. Not even a simple one like C. You learn the parts you use, and google for more stuff as you need it. Occasionally it means you'll write an algorithm instead of using a built in, but the time lost is generally minimal. If it isn't, you'll probably think "I wonder if this already exists" before you finish.

Re:Never thought I would hear about Legacy Ruby

[gl4ss]

sdk's come and go..

look, nobody cares nowadays if I know symbian c++. they do care that I've been working for 15 years making apps for handsets.

people care even less that I could do vesa 2.0 programming for dos. they might care that I knew enough to download the few docs needed for accomplishing that back in the day.

and back in the day.. people would get jobs for symbian programming purely because they knew enough to compile something. now there is a market surely for jovial only programmers, but hey come on if you think about that, they never went an extra mile.

real reason for why someone would stay on that would probably be that nobody expects you to churn out code quickly in the usual gigs for that sort of a language.

there's plenty of older guys who have had the luxury of churning out just few hundred lines of code per year - or even less, being a resident programmer at whatever bigger company doing just one specific part of some huge budget thing. very few people from my generation ever had that sort of luxury. sure it would be nice. I would probably still enjoy trying to crunch down some mobile java to smaller kb size. nobody is going to pay for that though, not even those who should.

sometimes you know a sdk is going to be goneski in a year and the app you're making will never make it's money back on that platform.. but even then plenty of companies wanted to make windows phone apps.

Re: Never thought I would hear about Legacy Ruby

[Anonymous Coward]

"C lets you do what you want"

That is exactly the problem. Thank you.

This sumurai knife can do it all: kill peasants, penetrate armor, cut bamboo, you can also use it to cut cheese I guess.

Clueless C nerd: oh yeah! Because it can do *everything* it is the *best* tool to cut cheese and butter our bread!! If you can't handle it, it is because you are not skilled enough!! That is clearly the way to reason about these things.

Re: Never thought I would hear about Legacy Ruby

[sg_oneill]

As a former COBOLcoder I swear to god Iâ(TM)ll quit the industry if that god forsaken language ever gets resurrected by the hipsters. Lifeâ(TM)s too short and Iâ(TM)m alread half of the way thru it so no cobol bad

Re: Never thought I would hear about Legacy Ruby

[sexconker]

Nah. A samurai knife would be terrible for cutting cheese or buttering bread.

For cheese you want a wire or at least a knife with holes.
For bread you want a serrated knife.

Re: Never thought I would hear about Legacy Ruby

[K. S. Kyosuke]

I'm fairly certain that's less of a problem and more an useful indicator of the kind of people you don't want to work with.

Re:Never thought I would hear about Legacy Ruby

[Anonymous Coward]

Thanks for the tall tale, old man. Let me clue you into how I know you're lying:

Good programmers never get any gigs. They don't get the gig without five years experience in your favorite fad language. The ability to learn a new language on the plane is not a skill which employers like you actually value no matter how many times you lie about it.

Continue hiring morons and sycophants, Bruce. We all know you don't hire any programmers.

I think you need to separate the code monkey jobs you are applying for and CS jobs. Computer Scientists can pick up any language in a few hours and always gets hired before everybody else.

Re:Never thought I would hear about Legacy Ruby

[Anonymous Coward]

Or when they do update it it's safer and more cost effective to add to the existing codebase than replace it entirely.

Re: Never thought I would hear about Legacy Ruby

[angel'o'sphere]

That is why modern languages have strong IDE support.
That mostly eliminates the need to learn 'standard libraries' completely.

Re: Never thought I would hear about Legacy Ruby

[Dynedain]

I came in to cleanup a project built by one of those guys. 2+ decades of experience and a Java architect. It was a PHP sure where he used factory factory factories to initialize the entire codebase.... completely ignoring that in PHP you get a new thread for every request. He left when he couldnâ(TM)t figure out why the web server had to be forcibly rebooted on a 45m cronjob.

The same site also used inline static JS to set the destination of top menu items:

Itâ(TM)s important to understand how a language behaves in context, not just be able to pick up languages fast.

Re: Never thought I would hear about Legacy Ruby

[jon3k]

You don't need to. Nobody knows the whole standard library of any language now.

I don't think he was implying you needed to memorize it all. But you need to be pretty familiar with large portions of it to be even reasonably productive, which can take weeks/months. Of course you won't know 100% of it and you'll learn more as you use it, but spending only a couple hours to learn the language you can't possibly know enough of the standard library to claim you "can program in X". That's more like "I'm still learning X".

Re:Never thought I would hear about Legacy Ruby

[Anonymous Coward]

True, but I've seen some people write new COBOL programs rather than opt for CL, RPGLE or Java...
Still has it's uses.

Re: Never thought I would hear about Legacy Ruby

[Junta]

All this talk is acting like C's general behavior is broadly a security problem and you can't have a language that empowers the user and be secure, but we can get more specific.

The biggest one is no innate range checking. Understandable, as range checking in the optimal case would at least require a handful more operations per array access, and particularly decades ago that was not affordable. In terms of capability, this isn't a capability anyone needs. One could argue that it robs users of the ability to deliver the fastest possible array indexing when they know it to be safe, though I wager that compiled languages at least have a shot of detecting most of the truly safe snippets and skipping range checking for static sized lists indexed only by constant numbers that can be compile-time checked.

Another is that the programmer must manually assure that strings have a null byte at the end. Again, being able to have a string and then not put a null byte in it is not something that has any practical application whatsoever.

Then there are various standard library functions that must be carefully used or not used at all.

Essentially, none of this seems to be issues of empowerment, they just demand more of the programmer to roll their own methodology to prevent common bad scenarios. There isn't any empowerment associated with being able to write the 15th byte of a 10 byte array.

Re: Never thought I would hear about Legacy Ruby

[Junta]

I will say I'd rather deal with the ramp up of a programmer as they fail to be aware of a standard library feature than someone who has more time in with the language I want but seems to lack good problem solving skills. Particularly with code reviews, you can recognize patterns that are bad.

Of course, if you have a blind leading the blind scenario, that can't be good. I once sat in with a java team and a developer with over a decade of java experience was asking me if I had any thoughts on why file copies in his code were slow. I immediately recognized that he wrote a file copy routine from scratch and found out he was completely unaware that java had a standard file copy routine. No one on his team even thought about that possibly existing. Knowing that was their most senior and respected developer, it suddenly explained to me a lot of their quality problems.

Re: Never thought I would hear about Legacy Ruby

[Junta]

I think the issue would be if you are very familiar with one particularly rich standard library (e.g. Java) you know there's something to look for in another language.

The things that can be missed are obscure realities of a language that tend to also be missed by veterans. In my experience, for example, even long time python developers are frequently unaware of memory views, bytearrays, and such that can speed up a large class of functions dramatically or make things a lot easier in general (I too often see a binary string converted to a list through list comprehension and ord(), as the usual go to for people unaware of bytearray).

Re: Never thought I would hear about Legacy Ruby

[Junta]

Of course, only if you know where to look. If you don't know a standard library function exists, you may waste time rolling your own, and probably not as good as the language runtime provides. No IDE is going to look at your function and recognize there's a standard library equivalent.

Re: Never thought I would hear about Legacy Ruby

[AuMatar]

No, you don't. I've done it multiple times in my career- you learn the syntax and jump in, picking up the library as you go along. It just means you sometimes write a bit of extra code. I wouldn't put it at expert level on my resume, but you can be reasonably efficient and get tasks done. Remember we used to program with minimal libraries and still make progress in new languages. You just might write a bit of redundant code that gets cleaned up (or not) later.

Re: Never thought I would hear about Legacy Ruby

[orlanz]

Most of the really good programmers can learn a new language on the plane to their new gig.

Not that extreme, but my assumptions are the same. I assume that a good programmer can pick up a language over the weekend and after two months of daily use, can become an expert at it.

But I find many candidates in the very old & very young buckets that appear to want to remain experts in their language of choice. The older group, I understand, they are basically retiring in 5+ years and just want the easy slide into it. Money isn't that important anymore and, with that out, there is plenty of opportunities in their niche.

Even HR departments writing job applicant forms will demand years of experience for specific language. You can't tell them "who has programmed in a mainstream language over the last 5 years." That's too vague. But I can review the resumes to find good contenders... even if they will take time to catch up to a team. I want a "programmer" not a hammer swinger!

I don't know if this was different before my time or it's just my localized perception, but it feels like the Programming field has become more like the doctors' field. "I am a neuro surgeon, anesthesiologist, or general physician; so I don't do Y."

But programming is (at least to me) nothing like that!

Re: Never thought I would hear about Legacy Ruby

[Anonymous Coward]

If it doesn't have a null byte at the end it is not a string.

Re:Never thought I would hear about Legacy Ruby

[Anonymous Coward]

RUN, Spot, RUN!!!

Re: Never thought I would hear about Legacy Ruby

[angel'o'sphere]

No IDE is going to look at your function and recognize there's a standard library equivalent.
Every IDE does that. Did you ever use one?

Re:Never thought I would hear about Legacy Ruby

[Anonymous Coward]

Fuschia is a mix of c and c++... not just c btw.

Re:Never thought I would hear about Legacy Ruby

[HiThere]

Learning a new language is easy. Learning how to use it is difficult. Learning the system specific libraries can be a real pain. Even in the languages I'm most comfortable in, I still need to drop into looking up references whenever I want to use a library I haven't used frequently.

Re: Never thought I would hear about Legacy Ruby

[jon3k]

So you're claim is you can be "reasonably efficient" in a language after spending a couple hours with it? Maybe we just have very different ideas of what "reasonably efficient" means.

Re: Never thought I would hear about Legacy Ruby

[careysub]

I think he is describing an "80-20" rule or some-such: that coding common tasks using standard libraries can be accomplished in a few hours, especially drawing on decent example code. Yes, you can get stuff done that way in a reasonably productive way, especially if you have experience in similar languages (all languages draw on previously used syntaxes and paradigms).

But yes, you are only just learning the language.

Re: Never thought I would hear about Legacy Ruby

[Anonymous Coward]

Lul. Yea because learning a language is just learning the syntax.

You and Bruce are delusional.

Re:Never thought I would hear about Legacy Ruby

[Anonymous Coward]

The thing is though Java has it's niche. Ruby's niche was providing features that other languages didn't have, but it lacked a lot of the enterprise features others did have. Now that those Enterprise oriented languages and libraries are catching up to Ruby on a lot of the features it's not likely Ruby will be kept around.

Re:Never thought I would hear about Legacy Ruby

[DrXym]

What a marvellously dumb argument.

Re: Never thought I would hear about Legacy Ruby

[Anonymous Coward]

One of the problems with C is that it gives bad programmers enough rope to hang themselves

Or maybe these bad "programmers" should stick to their code.org crap and leave C alone until they are actually compentent enough to check for errors without bitching about it.

This isn't a "design flaw" in C, this is C doing what it's expected to do. These errors and pit falls are known, if you as a programmer can't train yourself to avoid them then you shouldn't be using it.

To use a different example, C is like a gun. In the right hands it can be a lifesaver, in the wrong hands it brings nothing but destruction. Just because you're given enough rope to hang yourself with doesn't mean you have to hang yourself with it. The main issue is that people use C who don't have the time or patience for it, typically those under an arbitrary deadline set way too soon, and the result like anything else in an insufficient resources scenario, suffers.

If you want to use C, learn how to use it first, and make smaller libraries that are easier to debug and replace if needed. Large code libraries, especially in any newly written codebase, are much harder to debug and much easier to hide logical errors in than smaller libraries written for a specific purpose. In short, break down your problem correctly and design the program properly first, then write the code. If management then comes in and says "We need X too" tell them "OK, it'll be in update 1.4, unless you want to pay extra when that crap inevitably gets hacked, and we get sued, because you want to shoehorn it in post design stage."

which makes it harder for processes (code review and various levels of testing) to police issues.

Most places don't do this. So either you're at an old style shop which should know better than to allow shitty C code, or you're at some place that deals with systems programming which is a whole different beast altogether and they should still know better. Or you're just whining that it's not automagicly done for you again, so which is it?

Hint: Even the automagic crap misses things. It only takes one exploitable bug in the right place to get a total compromise. Even your JIT languages can be exploited for this. In fact, they are actually worse due to the fact that they generate code at runtime that cannot be verified. Sure you can check the source code for bugs, but did you check the VM? How about that last update? What about under these power saving settings where opcodes X,Y, and Z are disabled and A,B, and C are used by the compiler instead? On all the supported platforms and their CPU variants? This list goes on. Nevermind compromise the VM thread and you've got a good foothold in userland on the target that can potentially generate new code to break into kernel mode. WebKit anyone?

With a language that is safer by design then provided the compilation process is dependable, it should be safer

Emphasis mine.

Safety is in the eye of the beholder. As you've already pointed out there's plenty of room for error there. It may not be exploitable now, but new attack methods are searched for all the time, and what's "safe" now may not be in the future. See also prefetching and meltdown.

Also even if it is "safe", that shouldn't excuse anyone who calls themselves a programmer from being lazy and not caring about the errata of their language of choice. It's their job to know the pitfalls and to do their best to avoid them. Not ignore them completely because "someone else should do it for me."

even with that, formal proof that the code encodes the specification is rarely done. Even with code that is correct, the specification (if it even formally exists) may not be, and modern systems are made from numerous components, and the architecture may be incorrect.

All human failures, not the fault of the language. In fact, that's the reason C has stuck around for so long. Yes, you have a lot of rope to hang yourself with, but that rope is needed sometimes to deal with the issues of those already hung.

Re: Never thought I would hear about Legacy Ruby

[AuMatar]

Or maybe my definition has less to do with knowing every trick of the language, and more with getting tasks done. There's two major things here:

1)Actual coding is only 10-20% of programming. Architecture, debugging, organizational skills, etc are far more important, and are almost completely language agnostic. There were definitely subtle you would have trouble finding because they had to do with language tricks/oddities, but most bugs are logical bugs.

2) You can be reasonably efficient and not do everything the best way. I don't care if you use a for loop where a foreach would be slightly better, both do the job. Spending 1 minute to write trim() instead of using the library version would still be reasonably efficient (although for such a common function I would probably google to see if it exists first, this is just an example).

Last time I did a major language change, I was finding root cause and fixing bugs in the codebase within a day, because I could find where they'd have to be by logic alone. I'd consider that being reasonably efficient.

Re: Never thought I would hear about Legacy Ruby

[q_e_t]

There are use cases for lower overheads but for, say, processing your bank account, you might accept lower performance for accuracy or security. Even where performance is critical, accuracy might be too, although it the program embedded in my washing machine got the length of the spin cycle wrong by 10% I might not care, but if it got stuck in an infinite loop I might. To be fair, with something like that, produced in the millions, a higher degree of testing is cents per unit. Control of inputs before, say, an array access, gives more confidence in that testing.

There are areas where a subtle array bug might be hard to detect. Having worked with neural networks, I can attest that classification behaviour can be good, even with bugs in a library.

I like C, although I used BASIC, Fortran, Pascal Modula-2 before it, but a good range checking mechanism with the option to turn it off if you need it is handy. It's not as neat syntactically as some other languages, but the overloading operators in C++ brings its own dangers

Re:Never thought I would hear about Legacy Ruby

[haruchai]

I once interviewed a programming candidate, sent to me by a recruiter, who had only programmed in JOVIAL for his whole career and only wanted to program in JOVIAL for the rest of his career. I guess my business didn't matter much to that recruiter.

Most of the really good programmers can learn a new language on the plane to their new gig.

In the case of that candidate, it's probably not a good idea for him to try switching languages; he'd end up writing JOVIAL code in Java or Python, would look like a literal translation of German into English, or worse.

Re: Never thought I would hear about Legacy Ruby

[Aighearach]

I find it is generally as simple as using one (1) high-level library for that stuff per application, such as apache apr https://en.wikipedia.org/wiki/... or glib from Gtk.

In the case of embedded programming, I have to ensure security, tools that want to protect me from myself aren't even going to fit well and have access to all the IC features.

The problem with Ruby, for me personally, is that I can't fit it on small microcontrollers. It isn't enough to have an ARM with lots of features, you have to have a huge amount of RAM even for mRuby. It means requiring a system-on-chip that is probably capable of running linux.

It would be nice to have a hybrid version of Ruby where you could give up the dynamic features in return for those parts running without the interpreter, just using a C api. Then as long as I didn't try to do something dynamic, I could write Ruby code and compile it for 8 bits or something. But I'd just be using the control structures, data structures, class system, and compile-time error checking. And if I tried to do something dynamic, I'd get a nice error message. And if I really wanted it, I could upgrade to bigger hardware.

As it is, I'm using C at least part of the time. Hating C would be very limiting. One of the best things about Ruby when you need a high level language is that C integration is simple and seamless.

As far as strings go, there are always functions available to handle them either way, raw or as C strings, so splitting hairs is silly.

Re: Never thought I would hear about Legacy Ruby

[Aighearach]

I'm practically a cheesivor, and I disagree strongly. For firm cheeses, a chef's knife is ideal. For soft cheeses, a cheese knife or straight fruit knife.

For crusty breads with soft interior, you want a serrated knife. For non-crusty breads or breads with a firm interior, a chef's knife is much more effective.

And if you fancy yourself so well dressed that you have brioche for your bread, a serrated knife is going to send serious crumbs flying, to be sure.

A samurai's knife, or even his small sword, would be just about perfect for cutting most cheeses or breads. It is sharp enough not to need to need serration if you have good cutting technique.

Re: Never thought I would hear about Legacy Ruby

[Aighearach]

I personally keep the API documentation open while I'm coding anything serious, even if it is stuff I use frequently. It only takes a couple seconds to glance at a function signature, and surely I'll read more if I have doubts instead of just forging ahead and waiting for failed tests to save me.

I'm not going to learn a whole API on the plane, but why would ever need to know a whole API? I'll need to know a few functions at a time, and they'll change depending on what part of the code I'm in. The real problem in a new language is that I'd botch the architecture before even implementing the code. But implementing my monstrosity shouldn't be a problem, or require a bunch of memorization.

Re: Never thought I would hear about Legacy Ruby

[Aighearach]

I don't really even want to know what the tricks are, even using my main language!

If I was using Ruby and something was hard, I'd use C. If I was using C and something was too hard, I'd use ASM. If it requires a trick in ASM, it wasn't even a trick it was a processor feature.

My advice in Ruby is, use baby-Ruby. My advice in C is, use baby-C. My advice in ASM is, don't complain, upgrade until you can do it in C.

In Perl they have ideology that prevents that from being good advice. The good news, they have enough tricks to do anything.

OTOH, many languages require knowledge of specific build tools, and often that strongly determines the required organization. If you're using a new language, expect your packaging to suck and be obviously newb.

Re: Never thought I would hear about Legacy Ruby

[Junta]

I have used several. If I write a function called copydata that takes two filenames and then does an open on both of them and manually reads from one and writes to another, I have not met an IDE that will say "hmm, the way that function works, you *sure* you shouldn't be using this standard library function?

Sure when you try to make one and shadow another, it will point this out. Completion may complete a function name that you were about to do and give insight. If you however do not get caught by one of those two mechanisms (you function name differs from the standard library), the IDE isn't going to anlyze functions and suggest stdlib alternatives.

Re: Never thought I would hear about Legacy Ruby

[sexconker]

For firm cheeses, the benefit of a wire or a knife with holes is that you can slice and release. Otherwise it just gets stuck to the knife. For soft cheeses, anything will do for cutting it.

I wasn't referring to cutting bread, but buttering it (which is what the post I was replying to mentioned). A serrated knife is best there because you can angle the knife to control the spread, as it alters the gap between the bread and the scallops in the knife. The teeth of a serrated blade also help spread butter that isn't fully soft.

A samurai knife would have a flat blade and the cheese would stick to it compared to a wire or knife with holes (or at least explicit shallows for release). No samurai knife is sharp enough to cut a hard crusted bread cleanly. It will always crush, rip, and tear. This is why we design cutting tools with small teeth and spin them rapidly. No matter how sharp you get something, you can't get a clean cut through hard / crystalline materials. So we do a lot of fast, controlled tears.

Re:Never thought I would hear about Legacy Ruby

[e70838]

Java is declining because of Oracle. If Oracle made Java opensource with no strings, there would be a huge regain in popularity. IMHO the trial against Google has hurt a lot the reputation of Java.

Re:Never thought I would hear about Legacy Ruby

[DrXym]

This is an odd statement because very few programmers are so stuck in a rut that they only ever program one language or technology their entire careers. I've programmed Modula 2, Pascal, C, C++, C#, Java, Javascript, JavaFX, Rexx, Groovy, Typescript, Ruby, Perl, Obj C, Visual Basic, TCL, LUA, Rust and more besides. Using stacks, APIs and protocols too numerous to count, many of which are defunct. On numerous operating systems, some defunct.

It doesn't bother me if a language or tech dies because my skills are transferrable. I'm rather partial to Rust but if it were to die tomorrow I wouldn't feel it was ever a waste of time learning it.

Re: Never thought I would hear about Legacy Ruby

[DrXym]

As you say you can easily break it and that results in more time spent fixing bugs, more customer issues, security / exploit problems, potentially catastrophic failures where somebody dies.

C feels empowering after coming from a high level language but it's a very badly designed language, understandable in the 70s but not today. Unsafe functions are not deprecated, compilers are incapable of warning of issues, undefined behaviour lurks in functions, the runtime simply crashes (or worse doesn't). Same applies to C++ which has its own mess of issues on top. A veritable cottage industry of tools, linters, bounds checkers exist to try and catch problems that these languages allowed to happen in the first place.

Personally if I were writing something that required the performance of C or C++ these days I would look at using Rust because it takes the sensible approach of stopping errors from happening in the first place by design.

Re:Never thought I would hear about Legacy Ruby

[parkinglot777]

Or when they do update it it's safer and more cost effective to add to the existing codebase than replace it entirely.

Cost effective, could be. Safer? I don't know and won't guarantee the claim at all.

Re:Never thought I would hear about Legacy Ruby

[parkinglot777]

Err. I misread, perhaps. If you are talking about COBOL itself, then it could be safer. If you are talking about replacing COBOL with other languages, then it is what I said earlier.

Re: Never thought I would hear about Legacy Ruby

[angel'o'sphere]

The moment you type 'copy' the IDE will show you all functions with 'copy' in the name and a snippet of the documentation ...

Which you chose is up to your investigation or knowledge.

Re:Never thought I would hear about Legacy Ruby

[Anonymous Coward]

Java declining? From Hadoop to Cassandra, from Netflix to Youtube; if any it seems to be omnipresent. Even in the age of micro-services and Docker Java found ways to dominate.

Re:Never thought I would hear about Legacy Ruby

[michael_wojcik]

I don't think it's the case that COBOL is popular in old systems as much as nobody dares to update the COBOL in old critical financial systems.

Oh, it gets updated. We sell a lot of COBOL development tools. There's quite a bit of new COBOL development, too, because many large organizations have significant numbers of COBOL developers.

In many cases they're still working with old-fashioned COBOL, but some have moved to COBOL-85 (which at least has decent scope terminators and some other useful features), and others have even adopted OO COBOL.

Modern managed OO COBOL is actually pretty nice in some respects, with all the features of its environment (JVM or CLR). Properties, type inference, anonymous inline delegates, event combining, and so forth.

Re: Never thought I would hear about Legacy Ruby

[Hognoxious]

And if he'd called it "dataduplicate"?

Re: Never thought I would hear about Legacy Ruby

[Aighearach]

If a firm cheese is sticking to the knife, sure, don't be embarrassed, just use a wire. Not everybody is going to have the dexterity to maintain the optimal cutting angle throughout the stroke.

But a samurai who was that ham-handed would be expected to commit suicide before putting on training wheels.

Re: Never thought I would hear about Legacy Ruby

[sexconker]

No cutting angle will help. Cheese will stick to a flat knife in a hurricane.

Event-driven I/O doesn't require Node

[Bruce Perens]

Event-driven I/O is a good idea. It happens that Node already has a good one because it's a web standard, and it inherits it from Chrome along with the rest of Javascript. However, event-driven I/O is easily done in C, Ruby, Python, Java, anything that supports coroutines. Many of these languages also support lambdas, anonymous blocks, and closures. Yes, even C++ has lambdas and will have futures (like closures) in the next standard. The syntax for them is sort of clunky next to Ruby.

C programmers haven't just learned about select() and poll(), they've had them for a long time. These allow them event semantics on the existing Unix I/O primitives and you can build an event I/O library on top of them.

Javascript doesn't really offer all of the desirable features of modern programming languages. After all, the goal was for it to look like C. We'll end up with a nicer language with a first-class event-driven I/O library and no native I/O.

Re:Event-driven I/O doesn't require Node

[Billly Gates]

Event-driven I/O is a good idea. It happens that Node already has a good one because it's a web standard, and it inherits it from Chrome along with the rest of Javascript. However, event-driven I/O is easily done in C, Ruby, Python, Java, anything that supports coroutines. Many of these languages also support lambdas, anonymous blocks, and closures. Yes, even C++ has lambdas and will have futures (like closures) in the next standard. The syntax for them is sort of clunky next to Ruby.

C programmers haven't just learned about select() and poll(), they've had them for a long time. These allow them event semantics on the existing Unix I/O primitives and you can build an event I/O library on top of them.

Javascript doesn't really offer all of the desirable features of modern programming languages. After all, the goal was for it to look like C. We'll end up with a nicer language with a first-class event-driven I/O library and no native I/O.

Your post reminds me of a funny video from the same author who did the infamous Mongo DB WEBSCALE called node.js is Bass Ass rockstar tech which talks about event-driven I/O and the hilarious obvious problems .

Re: Event-driven I/O doesn't require Node

[Anonymous Coward]

Why are you talking so much about JavaScript when the story is about ruby? I love Perl and believe perl will always be the best so now Iâ(TM)ve posted the same as you.

Re:Event-driven I/O doesn't require Node

[Bruce Perens]

I wonder about people who find Nawmal videos entertaining. To give you some background on that, I hate having meetings on text chat servers because everyone else types really slowly. Similarly, watching two CG talking heads go through a dialogue, and in a monotone, is incredibly tedious for me because I could read the same dialogue much more quickly and I expect more inflection in speech. And probably because I worked at Pixar and its predecessor for 19 years, I have much higher standards for CG entertainment.

That said, I get the point that some things scale better. But it doesn't really matter, because some things that don't scale nearly as well are still fast enough.

And whoever is comparing Apache and Node doesn't understand that Apache has its own internal event-driven I/O system, and had before Node was born. It just uses select() or poll(). I suspect this is also true for MySQL.

Re: Event-driven I/O doesn't require Node

[Bruce Perens]

Why are you talking so much about JavaScript when the story is about ruby?

Because I am one of those boring, pedantic people who insist on actually reading all of the way to the third sentence of the story, which said this:

The JavaScript framework Node.js, for instance, has become popular as it requires less memory to deal with numerous connections because of its callback functions...

Re: Event-driven I/O doesn't require Node

[Billly Gates]

Why are you talking so much about JavaScript when the story is about ruby? I love Perl and believe perl will always be the best so now Iâ(TM)ve posted the same as you.

Because the point of the video was about the cool kids who discovered non blocking I/O async event driven do not understand threading or code quality. Yes you can do something simple VERY fast ... but in actually node.js developers develop their own OS with threading and end up with call back after call back loop spaghetti.

What Ruby 3.0 is attempting to do is just this. It makes more sense to use threads and let the OS deal with assigning them to CPU's and ultilizing which set of code to execute next.

Re: Event-driven I/O doesn't require Node

[Bruce Perens]

I would definitely use Node if I was serving WebRTC. There aren't that many other solutions.

I wonder how many of those folks understand that they're actually programming a state machine. Which we have had forever.

Re: Event-driven I/O doesn't require Node

[h33t l4x0r]

but in actually node.js developers develop their own OS with threading and end up with call back after call back loop spaghetti.

It kind of sounds like you're not aware of the language features introduced in ES6 (3 major node versions ago).

It makes more sense to use threads and let the OS deal with assigning them to CPU's and ultilizing which set of code to execute next.

OK so you're saying that threads are a better concurrency model than promises on certain OSes? Let's hear why you think that.

Re: Event-driven I/O doesn't require Node

[Bruce Perens]

OK so you're saying that threads are a better concurrency model than promises on certain OSes? Let's hear why you think that.

We should start with the point that not everything that should have promises does, and it will take another couple iterations of the Javascript standard to get there.

Javascript I/O programming creates a hidden state machine. Threading makes it obvious what the states are and what their order is. Implementing a state machine in a switch statement generally does this too, although it's not enforced. Implementing them in promises gives you a state machine where the last state is the innermost block, or you refer to them by name instead of using immediate blocks and then it's a directed graph with no obvious or enforced order.

I don't really have a problem with promises as an I/O paradigm, it's the fact that it's harder to understand the code by reading it from the first line to the last than it would be with threading or even with most well-written state machines in switch statements.

I am sure we can solve this all with syntax.

Re: Event-driven I/O doesn't require Node

[ljw1004]

It's weird to have an entire discussion thread about ease of promise/callback programming without once mentioning async-await, the only thing that makes it humane. (or is that the syntax you were referring to?)

Re: Event-driven I/O doesn't require Node

[q_e_t]

To my mind, the state machine should come first, as part of the design, and then it should be implemented, not the reverse.

Re:Event-driven I/O doesn't require Node

[Jane Q. Public]

That's not really the point. Here's the point:

Because non-relational databases do not have data relations, yet most data you want to use is INHERENTLY relational, then that "screaming fast" database is offset by the custom programming (and programming time, and cost) required to create those relationships yourself.

It might be fast, but it only does what you tell it to do, and you want to know that customer ID 3894567025 made purchases 36021, 42573, 56819, etc.

In non-relational databases, you have to create these relations yourself.

GREAT if you have a huge company and unlimited budget.

Re:Event-driven I/O doesn't require Node

[phantomfive]

fwiw in the settings (on any particular video) you can have the video go 1.5x speed. Knowing that has made youtube much more tolerable for me when a transcript isn't available.

Re: Event-driven I/O doesn't require Node

[Megol]

Everything in computing is about state machines. OOP -> state machine, functional programming -> state machine, raw assembly code -> state machine, neural network -> state machine, ...

Re: Event-driven I/O doesn't require Node

[Megol]

That sounds like engineering, not hacking. Can't have that.

Re: Event-driven I/O doesn't require Node

[q_e_t]

Not agile enough?

Re:Event-driven I/O doesn't require Node

[angel'o'sphere]

Non relational databases of can have 'relations'.
Or how do you think graph based databases work?
Or in memory databases like Java's 'prevailer'?

Re:Event-driven I/O doesn't require Node

[jlowery]

Non-relational databases have field occurrences. Fields in a document are associated with other data in the same document. Those associates may contain values that occur in other documents' fields. You may have to do multiple queries to pull data from multiple documents (if it's a large data set), but the individual queries are fast.

No, you cannot do fast ad hoc queries in a non-relational document store. No, you don't have anything like normalization in non-relational databases. Yes, managing duplication of data across docs in a document store is problematic.

Re:Event-driven I/O doesn't require Node

[serviscope_minor]

Because non-relational databases do not have data relations, yet most data you want to use is INHERENTLY relational

But they are not webscale.

Re: Event-driven I/O doesn't require Node

[Bruce Perens]

I wasn't, and async/await does look more like threading (and maybe brings back the overhead of at least a lightweight thread, too).

Re:Event-driven I/O doesn't require Node

[Aighearach]

apache lets you choose between a wide variety of IO systems, and has since the 90s. That is simple sauce.

Re: Event-driven I/O doesn't require Node

[Srin Tuar]

Bruce; you would do well to actually read a bit about javascript before just guessing. Async/await is just synactic sugar over promises. Promises are just an easy to grok syntax for async FSMs.

Threading has been thoroughly trounced by async programming. It took a long time for people to realize it, but those of us who have been 100% async in C for decades know exactly why node.js is booming: because it does not offer threading or blocking so it forces people to write somewhat performant code. My biggest gripes with aysnc are that the local disk is still not truly aynsc down to the kernel level even with IO_NONBLOCK.

And fwiw, async IO is easier on JS because the entire pool of core and 2rd party libraries you find are all written to be async. JS never had to overcome the trauma of blocking and threading, and leaves no blocking landmines laying about. All the other popular scripting langs and java are burdened with synchronous programming concepts.

Re: Event-driven I/O doesn't require Node

[Bruce Perens]

I don't just read about Javascript. I am quite competent in writing it.

Why not? COBOL is still around

[Tony Isaac]

There is even an object-oriented version these days.

https://supportline.microfocus...

Re:Why not? COBOL is still around

[MichaelSmith]

There is even an object-oriented version these days.

I thought that was called Java?

Re:Why not? COBOL is still around

[iggymanz]

eh, COBOL including MicroFocus went OO in the 1990s.

No

[Anonymous Coward]

Ruby is fossilized dinosaur shit, all the olds who knew Ruby have been purged from the tech industry for being old, and none of the young techbros who get paid shittons of money for coding know anything about Ruby.

Ruby is fucking dead.

Re: No

[Anonymous Coward]

Look at the companies proudly using Ruby. One claims to be the largest Ruby gig going. Which spells a death knell for the language: if one company is so dominant in a language, it becomes prohibitively expensive to maintain its code, and is destined to be rebuilt in a more popular language to save costs in the long run

Re:No

[LostMyBeaver]

I think a kickstarter to raise money for a David Hasselhoff concert tour to raise Ruby awareness could work. It would become huge in Germany!

Survive? Likely. Thrive? Likely Not

[ndykman]

Code lasts a log time, so there will be users here and there. But, I highly doubt it will thrive. Python is gaining and has an advantage of very good interoperability with C libraries and improving overall performance thanks to projects like NumPy and the like. It's use in data science and other projects as well as in CS education will continue to help the overall implementations, Python competes in the language space that Ruby is in, and I think it does it very well, even with the issues around the 2/3 versioning. Honestly, Ruby is behind Python, and that gap is increasing.

The original advantages of Rails are disappearing. More and more of the MVC work is moving to the client side, and the server side is increasingly oriented towards just providing REST services. The amount of server generated HTML, a big part of Rails initially, is very rapidly decreasing. And while Rails is evolving, that legacy still exists. And other stacks have caught up. NoSQL make the ActiveRecord pattern much less needed for example. So, if you want raw speed in terms of time to implement, Node and the MEAN stack are really more competitive. Of course, that speed comes at a real cost and NodeJS has it own problems.

All in all, Buby faces enough challenges that will take too long to fix via language and runtime changes for its future to be vibrant. I expect it will fade in the face of Node, Python and even the resurgence of strongly typed frameworks (Java, C#, Scala) alongside newly revived languages like Erlang (and it's modern cousin Elixir) that embrace patterns for scaling that serve the whole modern web well.

Re:Survive? Likely. Thrive? Likely Not

[Anonymous Coward]

Until chef and other ruby based tools evaporate, Ruby will persist much as Perl has.

Re:Survive? Likely. Thrive? Likely Not

[Tablizer]

It's a security risk put too much of the app logic on the client side, let alone being tripped up on client-specific bugs. Then again, risk hasn't stopped a lot of questionable trends/fads.

Re:Survive? Likely. Thrive? Likely Not

[h33t l4x0r]

Honestly, it feels like Python is behind both Node and Ruby in terms of development (though not popularity). Where are new Python features? Why do current Linux distros still ship with Python 2.7? And why can I still in 2018 not shift() a goddamn array?

Re:Survive? Likely. Thrive? Likely Not

[Anonymous Coward]

Code lasts a log time

Oh, if only we were that lucky...

Re: Survive? Likely. Thrive? Likely Not

[tigersha]

Attracts lots of nerds in their moms basements. âoeHey, I played with booby last weekend!â

Re:Survive? Likely. Thrive? Likely Not

[Tenebrousedge]

Ruby has a better syntax and probably a better object model. I'm sure there are all sorts of good things about Python's current popularity. Tell me though, can we even call this "2/3" morass a transition at this point, or are we just going to deal with these two separate-but-equal codebases forever? Popularity is not meaningless, but language fundamentals matter too.

Rails is certainly past its peak, but it actually works just fine as a set of REST endpoints. I don't know why you think that the framework is mostly about HTML generation. I'm also fairly concerned if you think that NoSQL is ascendant, dominant, or entirely a good idea. SQL as a query language is likely to be more enduringly popular than the relational datastore per se, but neither are exactly dying out. If as you seem to be suggesting, Node development offers a rapid path to buggy code, I am probably going to steer clear of that one, too.

Ruby is a pleasant and concise language. From my experiences in coding golf competitions, it's usually 30-50% shorter for the equivalent line of Python code. If it had a speed advantage, or seemed likely to obtain one, I would expect it to win out over Python in the long run. As things stand, I would expect that Ruby will continue to exist as a glue language, and as a common point between things like Crystal and Elixir. The syntax ideas and standard library functions of Ruby may end up being more durable than the language itself; Python on the other hand has had far less influence on the design of subsequent languages.

Re:Survive? Likely. Thrive? Likely Not

[ndykman]

There's some good points here, but i would note that Python as a language has its fans as well and some would argue it is quite well designed overall. Personally, I find Ruby can be a bit too clever in places, but such things are a matter a taste.

I don't disagree that the adoption of NoSQL could be problematic, merely that those looking for speed of implementation are increasingly adopting it and it is displacing Rails. Fairly or unfairly, Ruby is often tied to Rails, and as interest in Rails subsides, it is a drag on Ruby as a whole.

Meanwhile, Python is getting a nice boost from use in Machine Learning and CS education and that may cement its future. It is used a lot in scientific computing and has been for quite some time.

But, Ruby may gain a foothold in another domain. The future is always uncertain, but I was to bet, I would bet it against it right now.

In the end, it says little about the quality of Ruby as a language. Worse is Better, after all.

Re:Survive? Likely. Thrive? Likely Not

[Anonymous Coward]

Buby is a pet name for the GP's grandmother.

Re:Survive? Likely. Thrive? Likely Not

[Tenebrousedge]

I think Ruby is almost clever enough. There's no concise way to send a method as a signal to a collection with the intent that it be applied recursively to any contained collections, one can only curry arguments in one direction, and of course there's no homoiconicity. Still, it's almost lispy. Python is slightly more influenced by the C-derivatives rather than Smalltalk.

What evidence do you have at this point of increasing NoSQL adoption? Most of the HN coverage is pretty negative, e.g. Why SQL is beating NoSQL. I don't think we otherwise have much difference of opinion on the general course of future events.

Ruby, Python, Perl.... yawn

[Excelcia]

There was another Slashdot story a few months ago that C was making a comeback. Now Slashdot ponders if Ruby, one of the languages that contributed to the "death" of C can make it another 25 years.

The answer is no. At least, not in the way it is now. I suspect that, like Perl and Python and other interpreted languages, Ruby will always have a little niche of users. There will always be projects that are well suited to the ease of letting your programming language do all the thinking for you, and which don't care about the performance hit. JIT, if it makes it into Ruby, will further extend this, especially for the (often rather vocal) crowd that thinks JIT is magick that makes an interpreted language just as performant as compiled. Unfortunately, there is no fairy here, and Ruby (like the ones before it) will never be a real boy.

A comment made by one of the developers of PiTiVi (an open source video editor done in Python) on the how-to-contribute page for that project actually sums up Python in general, and also extends quite well to my thoughs on Ruby and most others in the same vein:

GStreamer Editing Services, the C library on which Pitivi depends to do all the serious work. If you want to work on the backend, this is the way to go.

Which is a great summation for Python, and is so applicable to Ruby as well it could have been written about it. Great for quick and dirty little tools, good for a project framework perhaps, but if you want to do serious work, go to a C library. This will always be the case. Ruby and Python and Perl and even mighty Java, they will have their niches supported by adherents who expound some aspect of their garbage collection, or ease of use, or type safety, but for the real work, people will always turn to native code. In a few years there will be some new debutant... there will always be some new debutant, bright and beautiful in that sparkling ball gown, that will draw all the ooohs and aahhhs of the boys in the crowd and which will rally the people to cry "this... THIS is the one that will kill native code dead once and for all", and yet it will never happen.

Re:Ruby, Python, Perl.... yawn

[Jane Q. Public]

People are looking at this from the wrong perspective. No offense meant, but I think that includes you too.

I rather suspect that you are a long-time Windows-based programmer.

Of course C is more performant. It's not a high-level language. It is intermediate-level at best. That's why C++, for one example, is higherl-level and therefore easier to use but slower. And interpreted languages will always be to some degree slower, because of their very nature. But they are also capable of doing more with less programming effort, and that is THEIR forte.

Further, there are fully-compilable versions of Ruby, such as MacRuby and jRuby. They don't give up very much to become compiled; only a few convenience features.

As for C libraries, that's partly what scripting languages are FOR: tying together low-level efficient libraries into higher-level finished products.

You say "for the real work, people will always turn to native code" but that's plain BS. People and companies do not have time or budget to low-level-code everything they do. A smart programmer will use the language appropriate to the task, and that often means tying that "native code" together using higher-level languages.

Your opinion of Python, for example, is just wrong. Python, despite its language inconsistencies and weird significant-white-space formatting, has been adopted by the scientific community as probably the go-to language of choice. It may not be used commercially as much as some others, but it is going to be around a long time.

The long and short of it is: each language has its particular strengths and weaknesses. Industry watchdogs predicted the imminent demise of Ruby over 10 years ago. That hasn't happened. In fact only 2 years ago, experienced Ruby programmers in the US commanded the highest salary of any language. I haven't checked more recently. But the market is a good place to look when one is making such "predictions".

While Ruby is 25 years old, it did not gain wide attention in the United States until nearly 10 years later. So as a practical matter, in the US, it is 15 years old.

It is approximately as performant as Python, and has a more consistent structure and syntax, so I suspect the scientific community will eventually shift over to Ruby over Python, unless it skips that step altogether and goes into functional programming.

As for Ruby "scalability issues", that is a myth that has weirdly persisted for at least a decade, in the face of abundant contrary evidence. Here are companies that have had no trouble at all scaling Ruby: AirBnB, Fiverr, Github, Goodreads, Groupon, Hulu, Indiegogo, Kickstarter, MyFitnessPal, Pixlr, Scribd, Shopify, Square, Strava, Twitch, UrbanDictionary, WhitePages, and ZenDesk.

There are many more, of course, but those are just some names that people might recognize.

Re: Ruby, Python, Perl.... yawn

[tigersha]

Replace âseriousâ(TM) with âhigh-performanceâ(TM). 99% of the code in a video editor does not need absolute screaming performance (it is waiting for mouse events in any case).and 1% is the part that actually does the video transformation.

Most low latency GUI stuff runs directly on the video card in any case.

Re:Ruby, Python, Perl.... yawn

[AuMatar]

C is a high level language. A high level language is anything that's not a 1:1 mapping of instructions. Stop trying to redefine terms.

As for python being the scientific language of choice- that's just wrong. Its still C and Fortran. Serious scientific computing requires performance, nobody would dream of doing that shit in python.

Re:Ruby, Python, Perl.... yawn

[Anonymous Coward]

Tell that to my niece getting her PHD in Neurology? Her whole field depends on Python.

Re:Ruby, Python, Perl.... yawn

[steveha]

I suspect the scientific community will eventually shift over to Ruby over Python

Unlikely. The reason the scientific community is using Python is that Python has SciPy, a rich and powerful collection of libraries. The heavy lifting in SciPy is done by compiled Fortran library code. Right now a Python program using SciPy is nearly as fast as the same program written in Fortran, and Python is dramatically easier to use. And it probably doesn't hurt that Python added a matrix multiply operator (infix @), just for the benefit of SciPy users.

In science and engineering, Python is now benefiting from network effect, where everyone uses Python because everyone else already uses Python. For Ruby to steal these users it would have to do something dramatically better and to date Ruby hasn't even matched Python. And if Ruby did get an edge on Python I predict that Python would implement something similar and keep its position as the language for science and engineering.

Re:Ruby, Python, Perl.... yawn

[Anonymous Coward]

Did you know there are python libraries where it automatically detect that you are using numpy and converts your function into a CUDA/OpenCL kernel and moves it to the GPU.

There is a certain subset where performance matters and requires hand crafted code. Most of the time though python and the scientific libraries that come with it is good enough. Also most scientist don't mind waiting a bit for the result.

Re:Ruby, Python, Perl.... yawn

[Carewolf]

C is a high level language. A high level language is anything that's not a 1:1 mapping of instructions. Stop trying to redefine terms.

As for python being the scientific language of choice- that's just wrong. Its still C and Fortran. Serious scientific computing requires performance, nobody would dream of doing that shit in python.

Not anymore. These days a high level language is one that doesn't have a preditable mapping to instructions and memory access, C still has that, and C++ can have that if you use it right.

Re:Ruby, Python, Perl.... yawn

[Anonymous Coward]

It's not the 70s anymore.

There are a lot of high-performance written in C and FORTRAN, indeed, but guess what... you do not have to waste time defining trivial stuff (trivial for the human). Python (MATLAB, julia, etc.) are very used by scientists of all sorts because they can solve problems a lot quicker in higher-level-than-C languages, and let the computer deal with defining 1.1 as a float and 1 as integrer.

You may end up with a program that is twice as slow as C, but you took a lot less to write it up. If you're going to use that routine very routinely it might be worth to rewrite it in a more high-performance languages. But in science (or more specifically, academia) it's very frequent to go from problem A to an unrelated problem B, which is likely to require a totally different solution from A and therefore you'll need to write new code from scratch.

Re:Ruby, Python, Perl.... yawn

[Anonymous Coward]

A lot of scientific computing doesn't have to be high performance.

Re: Ruby, Python, Perl.... yawn

[Dixie_Flatline]

It depends on what you mean by scientific computing. My partnerâ"a machine learning researcherâ"has to do things in C, Python and Matlab. All three are common in the community. It's surprising how many people doing machine learning research are using things like Python.

But that's because for small networks, performance isn't actually a concern. Not everything is AlphaGo.

A friend of mine went from his Masters in Biology into a CS PhD. And he's mostly done things and continues to do things in Python.

Lastly, stop splitting hairs. C is a high level language, but we all understand that how close it is to a lower level language is what makes it appealing and fast. A simple language with just enough abstraction so you're not in assembly.

Re:Ruby, Python, Perl.... yawn

[serviscope_minor]

Of course C is more performant. It's not a high-level language. It is intermediate-level at best. That's why C++, for one example, is higherl-level and therefore easier to use but slower.

That's flat out not true. Bad C++ is slower than good C and bad C is slower than good C++. The only thing that makes C faster than C++ is the restrict keyword, which all major compilers support for C++ as an extension.

Idiomatic C++ is often faster than idiomatic C, compare for exampe std::sort to qsort.

Re: Ruby, Python, Perl.... yawn

[Anonymous Coward]

He said science not witchcraft

Re:Ruby, Python, Perl.... yawn

[angel'o'sphere]

C is not a high level language.
It is neither you nor JQP who makes those definitions, it is the professors in he universities giving CS courses.

You could nitpick that ANSI C has evolved far from old school K&R C, however K&R C was just a portable assembler, it was designed to be that.

There are people arguing that only languages like Lisp, Prolog, Haskel, OCml, SQL etc. are *really* high level languages. In other words: not even Pascal, C++, Java, C# are high level languages.

Re: Ruby, Python, Perl.... yawn

[angel'o'sphere]

C is abstracting away only two things: the names and amount of registers, and the way how you call functions/use the stack.
It is considered by academics not to be a high level language
Of course you could disagree ... that is up to you. But might lead to strange eyes when you get a bad grade in a test ..

Re:Ruby, Python, Perl.... yawn

[Anonymous Coward]

I am well aware that scikit-learn is written in Python. That doesn't mean Python is a good language. I'd argue Ruby is a better language.

https://www.reddit.com/r/linux...
https://www.reddit.com/r/linux...
https://www.reddit.com/r/linux...

Duolingo was talked about recently here on Slashdot. There's a podcast where they talk about how they switched from Python to Scala and how it helped them out a lot.

https://softwareengineeringdai...

Re: Ruby, Python, Perl.... yawn

[Anonymous Coward]

You are right on most of your points.
However, your points have some serious flaws. This use whatever to get it out fastest mentality is why so many companies end up with spaghetti code. As for scaling without troubble have you ask any of those companies how they scaled it so well. My guess is there were at least a few programer pulling a lot of overtime to get there.

Just because you can do something does not mean you should.

Re:Ruby, Python, Perl.... yawn

[jon3k]

C is a high level language. A high level language is anything that's not a 1:1 mapping of instructions. Stop trying to redefine terms.

Who's definition are you using? I consider C to be a high level language (albeit at the very bottom of them) because it's machine independent, so it allows abstraction of the underlying system implementation. I'm just curious how we define these things because I can't find a clear definition from anyone I trust.

Re:Ruby, Python, Perl.... yawn

[Junta]

In sceinftific computing, your developers are largely not programmers, but scientists. This is why Fortran has enjoyed more relevance in that field than everywhere else, it maps more closely to how they express and learn math.

It is also the case that when it comes to intensive operations, they are generally merely supervising standard modules. specifically, python scripts can supervise numpy code, and that implementation is what matters not the text the scientist is typing.

Essentially, they need a "glue" lanuage, they don't need the glue to be fast, they just need the pieces to be fast. They need languages that relate to their professional experience and/or a language that won't intimidate them. IPython and numpy are very prominent reasons why python has been relatively popular in scientific computing.

Certainly, scientific computing cares a lot about c and python, but they care too about python.

Re:Ruby, Python, Perl.... yawn

[AuMatar]

And according to them, anything that's machine independent is high level language. If you want a term for something more than that, come up with a new term and a new definition. Until then, stop muddying the existing ones.

Re:Ruby, Python, Perl.... yawn

[angel'o'sphere]

Citation please ;)

Or care to read this and shut up? https://en.wikipedia.org/wiki/...

Re:Ruby, Python, Perl.... yawn

[DCFusor]

Sadly, as a mostly-perl programmer, you're largely right. Perl just doesn't have the network effect it used to have, even though, as far as I can tell, Python and Ruby (and that fractal of bad design, PHP) were essentially incomplete copies of the perl ideas, but done "wrong" or to the current fad idea (that whitespace thing...) of the author - and all with different weak or duck typing which is really what makes it hard to move between them.

That said, I use C a lot, C++ when writing drivers for sensors and realtime stuff, and even use Inline::Python to save time figuring out the bugs caused by different duck typing when bits are involved. BTW, when possible (usually) Inline::Your_language_of_choice converts to C, compiles that, and makes it into a .so (in linux) for you and often at least in the case of Python, often reveals poor coding by people who sleep instead of ready-check since it runs so much faster than native python....Yes, Adafruit, I'm looking at you there. It's still easier to fix that than some unknown algo for type promotion when you're working close to metal.

Re:Ruby, Python, Perl.... yawn

[ediron2]

Great post generally, and I agree that Ruby is unlikely to 'get an edge' in scientific computing. That said, the difference in the languages tickles just beyond the reach of that last phrase -- I'm pretty sure the aspects of Ruby that resemble Lisp can't be bolted onto Python. Especially the blurring of code and data (a la Lisp) -- a 'bolt a feature on' response is nigh-on-impossible expressly because that vast range of python libraries won't work lisp-like code/data ambiguity.

Python's great, and as a scientist/data geek, I love working with SciPy. As a hacker, I love working with Ruby. The synapses they tickle are so far apart, they're not even orthogonal.

I've also noted a steady growth in Lisp-mindedness. Over Lisp's 60ish years, cLisp, Clojure, Ruby etc seem to be growing mindshare. Slowly, and in fits and starts, but growing. Lisp's ability to craft parsers and DSLs have gotten us to where DSLs like like LUA are mainstream. There are skunkwork Lisp-like languages in some top tech firms. Fun stuff, fun times.

Re:Ruby, Python, Perl.... yawn

[brantondaveperson]

That's why C++, for one example, is higher-level and therefore easier to use but slower

Both of your statements are the opposite of the truth. Well, apart from the one about it being higher-level, which might be true. It's not easier to use than C, and it's not slower.

Re:Ruby, Python, Perl.... yawn

[Dynedain]

Further, there are fully-compilable versions of Ruby, such as MacRuby and jRuby. They don't give up very much to become compiled; only a few convenience features.

A few conveniences like performance. I changed which build servers were running part of our monolithic process recently because it took 45m to run a step in JRuby that could be done with a native Ruby gem in about 10m.

Next up, replacing that Ruby gem with a NodeJS plugin that can do it in under 2 minutes... on the same hardware.

Re:Ruby, Python, Perl.... yawn

[steveha]

Especially the blurring of code and data (a la Lisp) -- a 'bolt a feature on' response is nigh-on-impossible expressly because that vast range of python libraries won't work lisp-like code/data ambiguity.

Ruby and Python are more similar than different: they are C-like or Algol-like scripting languages that have both object oriented and functional programming features. So I'm honestly confused that you are distinguishing them in this way. Could you please give me an example of something really LISPy that is possible in Ruby and not possible in Python?

Python has support for explicitly compiling a string into code objects, and then Python code can introspect and rewrite the code objects. This is much more difficult that the similar operation in a LISP because S-expressions containing tokens are much easier to work with. And I'm guessing this isn't the sort of hacking you mean.

There are two things about Ruby that I am aware of that are more hacky than Python and that you might like, but neither seems that LISPy to me:

First, because Ruby is very generous about what you can use in an identifier and will implicitly call functions, you can hack up a DSL that's really just Ruby in disguise. For example, there is a DSL called Cucumber that defines things like Given: and because Ruby allows punctuation like ':' in identifiers, and doesn't require parentheses, you can implement this by writing a function and naming it Given:. But Python has library modules like PyParsing, which IMHO is a better solution: just specify the language you want and the callbacks when the parser figures out what is being specified. It's a bit more up-front work but it's a cleaner and less hacky way to go. (And thus my bias as a Python user is exposed... I prefer the explicit solution even though there is more up-front effort as I think it will result in a cleaner solution with less total work in the long run. Ruby users may disagree completely.)

The other thing is that Ruby lets you extend the fundamental objects for things like integers. You can access the global object for integers or whatever and add new method functions or override built-ins. What is Monkey Patching in Ruby? This just freaks me out. Python lets you do whatever you want by making a new subclass: you can make a new class that is just like an integer but has some behaviors overridden or new behaviors added. That to me is the One True Way... builtins like integers should be your bedrock, totally predictable because they can't be overridden. Python is less permissive than Ruby, but even Python is more permissive than I would like... Python doesn't have a const feature built in, so you can't do this:

const FOO = 1

You can simply do FOO = 1 but other code could clobber FOO with a different value. So in Python you have to just learn to not clobber things you don't own, and in Ruby I guess you just have to not break integers for everyone.

By the way, it is possible in Python to make a class and then override assignment to members of that class. So you could make a Constants class, assign all the constants as member variables, and then override assignment to the class so that it raises an exception. But in my experience people just set up constants in modules and then try not to clobber them.

Re: Ruby, Python, Perl.... yawn

[DamnOregonian]

Lastly, stop splitting hairs. C is a high level language

At its core, not really. It could be implemented purely as assembler macros. Now of course, compiler optimization is pretty far into the realm of magical, so language mapping to assembly code can be pretty perplexing... but unoptimized, C is really just an assembly macro language with fancy name mangling.

So in short, I think you should stop splitting hairs.

I've done a significant amount of reverse engineering in my time that (iPhone, Android, Moto Razr flip-phone)
Compiled C is easy to infer from assembler. C++ and above, is a different story. C++ is still pretty low-level really, but the runtime required to make it work puts it somewhere between a low level language and a high level language.

Is it NOT a buzzword?

[Pezbian]

Money it it now /= money later.

It won't be relevant

[Anonymous Coward]

I work with Ruby (RoR) on one of my projects, and it's such a weird language. Even after almost 2 years with it, the syntax is still so quirky to me. It also has a strange mix of OO and procedural features, and the variable naming conventions are odd as well. One thing I really dislike, and maybe this is more of a Rails thing, is the minimalist culture behind it. Why are comments and documentation so discouraged? Anyway this has nothing to do with how old it is, as many languages are far older and still have tons of support. JIT compilation won't save it though because Node has already gained so much popularity and devs can now stick with a single language for the full stack (yay MEAN) or at least with the front- and back-end. Of course just like with any legacy product, Ruby will still be around in 25 years, but I don't think it will be relevant.

Re:It won't be relevant

[Anonymous Coward]

> Why are comments and documentation so discouraged?

I know this one. "The code is the documentation." Sadly, it breaks down really quickly when you get to the *next* page of a complex program.

Re:It won't be relevant

[OpenSourced]

Why are comments and documentation so discouraged?

The idea is that documentation is just a band-aid for unclear code, and it will in the end become out of sync with the code, causing further confusion.

Of course, for this to work you have to code very neatly, with a clear and obvious program structure, and functions that do just one thing and are named properly. That way, the names of the functions act as a way of safer documentation, as if you were coding in natural language, sort of. That's of course a lot more work than dropping a comment here and there, when you feel like something is not clear, so it's not so popular. I'm still undecided on the merits of the concept, will have to try it out some day.

Re: It won't be relevant

[Anonymous Coward]

Code doesn't necessarily tell you the intent of a section. Maybe the very best coders don't need comments, but they are rare and you probably are not one.

Re:It won't be relevant

[Escogido]

This is pretty much the blessing and the curse of Ruby - its philosophy works excellently for the best programmers (who are able to write clean and DRY code etc.), but is not really a good fit for mediocre ones, unlike Python or JS. And since there are always only so many best programmers, and majority is always average or worse, Ruby is sort of destined to be niche'y, which may ultimately spell its failure, or it may not. Personally I am enjoying coding in it, even though I am far from the "best programmers", but whether the language is going to last, I cannot be so sure.

YES

[Archladon]

Ruby on Rails can survive, yes, as it is robust enough to weather the various changes that have been taking place on the system architecture

Re:YES

[Anonymous Coward]

WTF are you talking, changing system architecture? HTTP is ancient. TCP/IP is ancient. SQL is ancient. AMD64 is ancient. Everything that runs your cloud of things is old, old, old technology. If you think the web isn't boring as shit, there's something fucking wrong with you.

Re: YES

[Anonymous Coward]

Perl still survive as niche language

Re:YES

[Anonymous Coward]

Dude, I hate to be the one to tell you this, but your calendar may be stuck on 2005.

Re:YES

[Megol]

AMD64 ancient? Guess I AM getting old :(

Re:You're asking the wrong question

[Anonymous Coward]

Until the gerbil chews through your bowels and drowns in your blood.

Fad Ahoy! [Re:It won't be relevant]

[Tablizer]

I know this one. "The code is the documentation." Sadly, it breaks down really quickly when...

I've seen stupid fads screw up our stacks and practices also. I don't have the office politics power to stop the idiocy. I'll just enjoy the Titanic's violin music while it's above water. I bet when it sinks, the fadboys will call it a "submarine".

Re:Fad Ahoy! [Re:It won't be relevant]

[Anonymous Coward]

It can work, if you have code reviews.
I sometimes have to work in code of an application that I do not know at the company I work for. There is hardly any documentation, but all code has been reviewed by up to three people. I have no problem figuring out what a piece of code does based on the naming of the function/classes/types/variable names and on the structure of the code.

Smalltalk/X, anyone?

[K. S. Kyosuke]

"With MJIT, certain Ruby YARV instructions are converted to C code and put into a .c file, which is compiled by GCC or Clang into a .so dynamic library file. The RubyVM can then use that cached, precompiled native code from the dynamic library the next time the RubyVM sees that same YARV instruction."

That sounds very much like Smalltalk/X to me. Will be interesting to see how well this works for Ruby. In Smalltalk/X, however, larger pieces of code were compiled ahead of time this way; the JIT compiler in Smalltalk/X to my understanding doesn't use the intermediate C route or generate .so files.

Can ruby survive? I hope not

[mveloso]

Every once in a while Ruby crashes and burns when installing gems...on a system seemingly identical to another one that works fine.

Once the Ruby guys can fix that I'm sure Ruby will do fine.

Re:Can ruby survive? I hope not

[Mandrel]

Compilation of Gem native extensions can fail on systems with restricted memory, such as VPSs for which swap space hasn't been configured.

Well, old languages, you know

[dwywit]

Ctrl-f "RPG"

It's still doing a lot of commerce, so why shouldn't any other useful language?

Re:Does the Tin Man have a sheet metal cock?

[Anonymous Coward]

https://youtu.be/2ChZ_KFY9PM?t=2m7s

Ruby versus Python

[Zobeid]

I think Ruby has been overshadowed by the huge success of Python. Recently I set out to learn a new high-level interpreted language, something for easy scripting and prototyping, somewhat like the role BASIC (at least in its more advanced variants) used to fill. I was drawn to Python and Ruby. They both made a similar sales pitch, they sounded good. But which would it be?

Well, I have a friend who is already a Pythonista, and it appears to have more mindshare all around.

In all my web searches about Ruby, I kept coming up with Rails, Rails, Rails. Ruby on Rails is great for web development! Ruby is a great language for web development! (In case you all haven't guessed, web development is something I have no interest in.) And, oh yeah, Ruby can supposedly, theoretically, be used to create stand-alone applications, though we don't really talk much about that.

The other thing that irked me was Ruby pushing OOP in my face, hard. In Ruby everything is an object! EVERYTHING!! (This seems to be true in Python as well, but they don't harp on it like this.) Then I look at the Ruby tutorials, and they immediately launch into discussion of classes and objects, before even basic stuff like flow control. Well, I'm one of those crazy geezers who thinks that OOP is oversold. Sometimes useful, yes, nice to have built into a language, sure, but there's no point in messing with it just to dash off a quick script or simple little application. If I just want to say Hello World, I shouldn't have to begin by defining classes. Didn't we go through that madness already with Java? Was no lesson learned? So, I got a tutorial book on Python. Classes are covered in chapter 22, not in chapter 1. To me, that's a lot more sensible. And if I merely want to use my classes as a slightly fancier counterpart of C structs, Python doesn't judge me.

By comparison, the only really dumb thing I've encountered with Python is its ridiculous use of white space. I guess I can learn to live with that.

Re:Ruby versus Python

[david_bonn]

I've used both Python and Ruby for years.

Personally I think Rails killed (or is still killing) Ruby. Largely because Rail apps scale poorly and beyond a very basic level become hopelessly unmaintainable.

I agree that Python is quickly becoming dominant in the scripting language space. Largely because of libraries like scikit. And bluntly, this isn't the 1980's anymore. Back in the day you coded in C except where you had to jump into assembly for a bit of speed. But these days I think the right design slice is to do the performance-critical parts in C (or maybe C++ or something similar) and use a scripting language as the glue code.

There are a lot of things about Ruby that I think are awesome and much better than comparable languages (my favorites is how the pattern-matching operator ties into switch/case statements and exception handling). But the world is moving on and sadly, Ruby is likely to be left behind.

Re:Ruby versus Python

[Anonymous Coward]

This might be moot in 2018, but I think the success of python, or in the very least the "sexiness" of python, has been hampered by the schism between the 3.x and 2.x releases. Although we are almost at the point where 3.x is gaining a ton of traction, it's a pretty crazy situation and not something you normally see.

Re:Ruby versus Python

[Zobeid]

I think it was a detriment for a while. As somebody who was interested in learning Python, it was a bit confusing and off-putting to me. However, I do get the feeling that Python 3 is over that hump now and the language can move forward again.

Re:Ruby versus Python

[Tenebrousedge]

You are wildly off-base with respect to Ruby, and in respect to OOP, "crazy geezer" is the kindest characterization. Ruby and Python are extremely similar as scripting languages. I don't know what you read about either language, but this is an offensively stupid post.

Re:Ruby versus Python

[Zobeid]

It's "offensively stupid" to simply relate what I have observed? I didn't make any of this stuff up.

Re:Ruby versus Python

[Tenebrousedge]

You did not invent any experiences. You're were sufficiently outraged by the idea of object orientation, because of your own inadequacies, that you stopped reading something that mentioned the subject. In doing so, you somehow missed that Ruby's "hello world" is shorter than Python's, and that in general the only difference in scripting is that Ruby has less required syntax. Not understanding such basic logical abstractions as classes is also completely absurd, but if you can say such things and remain employed then one presumes that you're not in a position to do much damage to anything.

Re:Ruby versus Python

[Zobeid]

quote: "You're were sufficiently outraged by the idea of object orientation"

I don't believe I wrote anything to indicate that I was outraged in any way by object orientation. I suggest you go back and read what I actually wrote.

quote: "you somehow missed that Ruby's "hello world" is shorter than Python's"

I don't believe I wrote anything about Ruby's "hello world" at all. I suggest you go back and read what I actually wrote.

quote: "in general the only difference in scripting is that Ruby has less required syntax."

I don't believe I wrote anything about which language has more concise syntax. I suggest you go back and read what I actually wrote.

quote: "Not understanding such basic logical abstractions as classes is also completely absurd"

I don't believe I wrote anything that indicated I have any difficulty understanding what classes are or how they work. I suggest you go back and read what I actually wrote, which was primarily a gripe about the presentation and "marketing", if you will, of Ruby rather than its technical characteristics. (In fact, I think the only criticism I made of a technical nature was aimed at Python's use of whitespace.)

Re:Ruby versus Python

[hoggoth]

> Ruby's "hello world" is shorter than Python's
Boasting that being shorter than THIS is important is just silly:

>>> def main(): ... print("Hello, world!") ...
>>> main()
Hello, world!

Re:Ruby versus Python

[hoggoth]

Sorry for the bad grammar.... I can't find my Slashdot edit button...

> Ruby's "hello world" is shorter than Python's
Boasting of being shorter than THIS is just silly:

>>> def main():
... print("Hello, world!")

>>> main()

Hello, world!

Re:Ruby versus Python

[Tenebrousedge]

puts 'Hello, World!'

It is certainly silly to suggest that one has to jump through fewer hoops to write a Python program. Nevertheless, that was the claim.

Re:Ruby versus Python

[Tenebrousedge]

It's really cute how you can pretend that you don't understand the context and meaning of those statements. I'm sure there's some mental gymnastics which will allow you to make your choices someone else's fault, but I'm not sure that this routine is a winner.

Re:Ruby versus Python

[hoggoth]

You didn't define a function, so neither will I:

print('Hello, world!')

You (Ruby) beat me (Python) by two parenthesis! Had I used Python 2 it would be a tie.

Re:Ruby versus Python

[Tenebrousedge]

Yes, since the original claim was that Ruby was forcing him into dealing with classes and things when he didn't wanna, it made sense to opt for the minimal expression. One might even do something like p"Hello, World", but p adds quotation marks to the output, so one might disallow it based on that. Note for the record that the space between p or puts and its argument(s) isn't required. For the purposes of writing small scripts it's almost not worth bothering to list the differences between Python and Ruby — print is also a Ruby function, so the exact code you give can be executed by either interpreter. Using a function:

def main
    puts 'Hello, World!'
end
main

or with a lambda you could do:

->{puts 'Hello, World!'}[]

The square brackets execute the previous lambda expression. I believe the equivalent Python would be:

(lambda : print('Hello, World!'))()

More or less the same thing, with Ruby having slightly shorter syntax. However, try this one:

puts(Enumerator.new do |y|
    loop { y.yield (1..rand(1..18)).map { [*'a'..'z'].sample }.join }
end.lazy.reject(&IO.readlines('/usr/share/dict/words').method(:include?)).first(10).join(' '))

This generates random strings which are guaranteed not to exist in the system dictionary, and writes them to stdout. The collection is lazily evaluated, so that we don't have to (explicitly) loop over the generator until we have the specified number of items. Technically, this is a single statement. Also, I should probably say that this was written as a joke, and I promise that I've never written anything like this in production.

What does it offer others don't?

[PmanAce]

I'm curious, never used the Ruby ecosystem, what does it offer that others don't? If nothing, isn't it normal to go the way of the Dodo?

Another 25 years?

[Anonymous Coward]

Another 25 years? Is it still alive today?

*Pokes with stick* ... ...
*quiver and groan*

Oh, alright then. Carry on.

Is this article about the C programming language..

[Anonymous Coward]

... or about Ruby?

Is it still alive?

[MerlinTheWizard]

I didn't notice. My bad.

Don't forget about crystal

[Anonymous Coward]

We also have the crystal programming language, which is pretty mature at this point (albeit still in alpha) and aims to be "slick as ruby, fast as C". My company uses it for all of our infrastructure in production.

Re:Don't forget about crystal

[HiThere]

Last I looked at Crystal it was pretty immature, but that may be a year ago now. How does it do with multiprocessing? Will it support guilds? (For that matter, with Ruby? And if so, when?)

To me guilds made me consider switching back to Ruby, but I haven't seen anything new about them, like, say, a working implementation, even if it had bugs or was slow, in the last year. I'm less interested in the faster execution (though that would be good) than in the easy, seamless, multiprocessing.

Re:Don't forget about crystal

[lasermike026]

How do you use Crystal in infrastructure code? Ansible offers so much.

Re: Don't forget about crystal

[Anonymous Coward]

So you are using alpha quality code in your production systems?

Yea. No one here is going to take your advice.

Re: e=&p!?

[Anonymous Coward]

What is the translator you used to write your comment? And what is the origina language

C maybe migrated to another superior language.

[Anonymous Coward]

C is a high level language. A high level language is anything that's not a 1:1 mapping of instructions. Stop trying to redefine terms.

C has many weaknesses.

I think that i will build a new language to substitute C and it will be very nice.

Once created this new language, the migration to it from C big projects will be expensive.

Ruby to Crystal lang or Python to Cython.

[lasermike026]

On Friday a fellow engineer asked me what I thought about Crystal lang. Crystal lang is a Ruby like language that compiles down to machine code. Intrigued I took a look. That language is similar to Ruby but it has static typing which has a performance advantage. I wrote some test code. It was fast. The language itself is a little different from Ruby. What makes Ruby, in addition to syntactic sugar, are gems. Crystal's analogue are Shards. I noticed that the style of Shards is more procedural and less object oriented. This is my first impression of the language. It left me wondering what I would lose if I migrated from Ruby to Crystal lang.

I love Ruby. I love the syntax. The performance can be an issue sometimes but there are workarounds. Let's be honest, Python won the war. Python solved many problems with it's built-in types, language simplicity, and good performance. For all Ruby's syntactic sugar Python grew and dominated. There are extremely helpful Python modules that have made entire industries. Performance matters.

When I tested Crystal lang I asked myself if there was an analogue in Python. Quickly I thought of Cython. I never had a reason to use it but I was looking for compiled self contained binaries that I could use on some of my weirder systems where installing dependences is difficult. I work in the docker space so Go seemed like a good choice. With in less that an hour I was producing statically linked binaries. My code was simple so I did not have to tackled the more complicated bits but it was a good first go.

Python in Cython is still Python. Crystal lang is like Ruby with completely different modules. What Cython is doing is different from what Crystal is doing. Cython is taking Python code converting it to C which and running it in an embedded Python interpreter. Crystal is producing machine code without an interpreter which theoretically has performance advantage. The advantages of Crystal may not out weigh the advantages of Python and Cython.

I applaud what the folks at Crystal lang are doing. I may not use Crystal because it doesn't fit what I'm doing but I would love to see them grow and develop. If I need something compiled from a scripting language I would use Cython over Crystal. Win 1 for Python.

Re:Ruby to Crystal lang or Python to Cython.

[iggymanz]

Python won the war? At my employer python is for analysis and "big data". Ruby is in totally separate realm for other purposes.

Does Ruby have an optimization keyword now?

[istartedi]

I'm given to understand that Ruby is slow in part because all objects can be "monkey patched" at run time. I've always taken it as the language where you can serve web pages from an integer if you like. 3X faster than old Ruby is still not fast, right? All the JIT in the world can't help you if there's no clean mapping from the language's objects to the machine's objects. You'd need some kind of "lock" optimization keyword in the language, and perhaps other fundamental changes.

Other posters have mentioned Python + ScyPy having a hold on the research community, with ScyPy being in Fortran not C. C got the *restrict* keyword relatively recently so it could optimize aliasing. Fortran has been restrict by default all along, so I suspect ScyPy is built in Fortran in part because people who work with it are used to faster aliasing assumptions.

I'm willing to wager that Ruby is still pretty far behind in all of that. It had a "just throw more hardware at it" mentality from the very beginning, and is only going to survive in areas where people can be convinced that it's easier and cheaper to do that.

Re:Does Ruby have an optimization keyword now?

[iggymanz]

Ruby isn't slow though.

Are you imagining most apps need to run at 100% of CPU speed 24x7?

typically in business world the database of an application is the bottleneck

Version 3, three-times faster?

[fahrbot-bot]

Ruby creator Yukihiro Matsumoto says Ruby 3.0 "has a goal of being three times faster than Ruby 2.0,"

Yukihiro. You know that's not really how version number work - riight?

Re:Version 3, three-times faster?

[Anonymous Coward]

Exactly. It should be 3.0/2.0 = 1.5 times faster.

Take Windows as an example. Install Windows 10 on a Pentium 4 (won't run on less).
We have that 10/95 = 0.10 Thus, Windows 10 will run at 1/10th of the speed of Windows 95 on such hardware.

Re:Version 3, three-times faster?

[hoggoth]

Right, because three times faster than Ruby 2.0 would be Ruby 6.0!

Ruby is great

[Anonymous Coward]

I use Ruby every day to run my blog and business. It looks like The fastest way to do things. I don't see why it will fall

Languages Hardly Ever Die

[Anonymous Coward]

There's no definitive mechanism, or even definition for language extinction. They simply become unpopular.

What really happens is that the evolution of the language slows down until it stops completely. The language stops being taught in schools. The practitioners thin down until they occupy offbeat pockets that can sustain them.

I mean, name one single computing language, that is completely extinct. 100% for certain. There are no developers, no code being written (don't forget hobbyists), no legacy applications. Not even in the various computer museums.

About a year ago I watched a series of videos. They concerned bringing an ancient Xerox Alto system back online. Someone always has an interest, even if it is mainly historical and to understand how our current tech platforms came to be.

Just... wow.

[Slartibartfast]

JQP? I think it is safe to say that -- with all due respect -- you were a ripe bastard back a few years ago. But I just read a solid handful of your most recent posts, and they are considered, intelligent, articulate... really, really good stuff. Thank you!

And, BTW, Ruby totally rocks. Best, most expressive, most intelligently done language currently out there. (Though in a late-night fit of stupidity, I admit I had cause to mourn the decision to use '=' for both assignment and object instantiation.)

-K