Ask Slashdot: Choosing a Web Language That's Long-Lived, and Not Too Buzzy?

adelayde (185757) writes "In my day job, I work on a web based service with a lot of legacy code written in that older (and some may say venerable) web-scripting language, Perl. Although we use Modern Perl extensions such as Moose, the language just seems to be ossifying and we're wanting to move to a more up-to-date and used language for web applications, or even an entire framework, to do new development. We're still planning to support the legacy code for a number of years to come; that's unavoidable. This is a fairly big project and it's mission critical to the business. The thing we're afraid of is jumping onto something that is too new and too buzzy as we'd like to make a technology decision that would be good at least for the next five years, if not more, and today's rising star could quite easily be in tomorrow's dustbin. What language and/or framework would you recommend we adopt?"

Comments

Perl

[XanC]

Perl 5 pretty much satisfies everything you're looking for. What's the problem with Perl again?

Re:Perl

[Anonymous Coward]

/&%#%^&*)^ADVkjR$%^$E)!HJLGAZ^&R%\jkghlk/^

Random garbage or valid perl?

Re:Perl

[trudslev]

Valid garbage or random perl?

Re:Perl

[Anonymous Coward]

It's too old. As far I can tell, there are exactly zero specific requirements mentioned besides it being something new but that'll stick around, and that the project is "fairly big."
 
My solution would be to talk to the smart friend of yours with the largest hands. The slap upside the head should solve the problem.

Re:Perl

[just_another_sean]

Nobody is forced to program that way in Perl. It can be fun and may or may not look cool on a t-shirt but no one recommends that as a way of doing it. Just because there's more than one way to do it doesn't mean you should choose the worst way.

And to the submitter, I agree with the OP.

Re:Perl

[Newander]

So your beef is with Regular Expressions?

Re:Perl

[NotInHere]

Using cable1:
$./cable1 "/&%#%^&*)^ADVkjR$%^$E)\!HJLGAZ^&R%\jkghlk/^" "random garbage" "valid perl"
valid perl

Re:Perl

[MouseTheLuckyDog]

Nobody is forced to program that way in Perl.

Mobody is forced to write Perl that way, but many people are forced to read that kind of Perl.

Re:Perl

[Camel Pilot]

Are you referring to reg exp? If so... it is you loss for not understanding reg exp.

Re:Perl

[azav]

And that regular expressions are as easy to understand and predict as Rob Ford is sober.

Re:Perl

[Mordok-DestroyerOfWo]

/&%#%^&*)^ADVkjR$%^$E)!HJLGAZ^&R%\jkghlk/^

Random garbage or valid perl?

Why can't it be both?

Re:Perl

[micahraleigh]

adoption

Re:Perl

[MBGMorden]

That's the crux of the issue. A good language shouldn't be one that lets you code cleanly - it should do its very best to make sure you CAN'T code sloppily.

Re:Perl

[rmmeyer]

Yeah, that was the theory behind ADA... We know where that went

Re:Perl

[Bill_the_Engineer]

The question that I don't see being asked: "Is there a 'web' language that warrants my employer paying me to learn and use?"

If I was an employer and had a lot invested in Perl, I would view any attempt to introduce yet another language into the shop with suspicion. Does the employee's suggestion merit consideration or is he trying to get me to pay him to learn a new language to pad his resume?

Would I rather have someone with years of experience using Perl work on my enterprise code or would I prefer to have someone with practically no experience in some other language or its associated framework using that language to develop my enterprise code?

Do I really want to fix what is not broken?

Re:Perl

[jythie]

Well, as a language it did that job pretty well, but yeah, not that popular. Though it could be argued that many of the things it did do well got integrated into later languages, so in a way it succeed in a wider sense even if Ada itself did not do well.

Re:Perl

[quarkalone]

Where?

Re:Perl

[Anonymous Coward]

That's the crux of the issue. A good language shouldn't be one that lets you code cleanly - it should do its very best to make sure you CAN'T code sloppily.

Yeah, but the OP is asking about web languages.

Re: Perl

[jd2112]

You can write illegible programs in any language, perl must makes it easier.

Re:Perl

[Sarten-X]

A good language ... should do its very best to make sure you CAN'T code sloppily.

Exactly, just like a good spoken language should make sure you CAN'T use profanity.

...But then, what about when profanity is appropriate? What if you need an emphasis that is so fucking strong that simply changing the tone of voice doesn't suffice? What if your whole damned speech is in reference to something condemned by a deity, or referring to Mohammed the thief, who assumed the name of the prophet?

The point of any language is to express. For programming languages, the idea is to express instructions for two different processing styles simultaneously: the deterministic and predetermined understanding of the parser, and the non-deterministic and subjective understanding of colleagues. Similarly, spoken languages must account for the subjective understandings of every listener, some of which may have very different rules regarding obscenity.

There is much more to coding "cleanly" than mere syntax. Structure is equally important, and it must change as the system design demands. If the rules of a language are too strict, then the whole program starts to look the same, and it's more difficult for future interpreters to understand the intent of the program.

There is an art to writing clean code, just as there's an art to writing eloquent language. Strict rules don't always improve that art.

Re:Perl

[HornWumpus]

As long as you were willing to make your mistakes in triplicate, Ada was happy to let you.

Re:Perl

[HornWumpus]

Regular expression are deterministic. Rob Ford, not so much.

Re: Perl

[GeekBird]

Agreed, which is why I get really annoyed with Python bigots. My main exposures to python have been trash piles like Anaconda and cowboy crap that is seven layers of libraries to implement and process check that has such poor syntax that it can't even fail, no matter how screwed the process.

I've seen incomprehensible junk written in tcl, bash, java, javascript, c, c++, visual basic, fortran, cobol, basic and assembler, most often written by "experienced" coders who think comments and structure are anathema and risky to their job security.

Give me "unsophisticated" and/or heavily commented code, thank you.

Re:Perl

[darkwing_bmf]

Ada (not ADA) is widely used in the Aerospace industry if that's what you mean.

Re:Perl

[darkwing_bmf]

But what if I WANT to design my bridge wrong? What if I want my blueprints to be misunderstood so that it could be built incorrectly and collapse after the first good thunderstorm? I should be allowed to do that right?

That's basically what you're arguing.

Re:Perl

[Cro Magnon]

/&%#%^&*)^ADVkjR$%^$E)!HJLGAZ^&R%\jkghlk/^

Random garbage or valid perl?

Yes.

Re:Perl

[gbjbaanb]

no, he's not. He's saying what if he has circumstances that mean the traditional or cookie-cutter bridges do not fit the situation he finds himself in.

Then there are also areas where you want to innovate somewhat. I mean, imagine an upside-down suspension bridge... that'd be so far stupid no-one would consider making anything like it, and any language that let you was brain-dead..... but someone went and made one anyway (even though it did suffer teething problems - such is the curse of making something new).

Sometimes you need the power to express yourself differently, and whilst there is a lot to be said for standardised systems that let you build standardised products, I'm not convinced the stuff that lets you build such standard sites are all they should be (esp. re security).

Re:Perl

[Xyrus]

/&%#%^&*)^ADVkjR$%^$E)!HJLGAZ^&R%\jkghlk/^

Random garbage or valid perl?

Spoiler: "DRINK MORE OVALTINE!"

Re:Perl

[HeckRuler]

Uhhhhhhh, I'd say there's two camps.

1) The sort that forces you to do something because that's a good practice. Good to learn on. "This is the way child".

2) The sort that gets out of your way to let you do what you want.

Take the semicoln in C. It's not needed. It's really just a pleasant confirmation to the compiler to let it know that your current statement is done. But it doesn't strictly need to be there for compilers to know that. It's certainly how the language was written and how all C compilers expect code to be written, but that aspect of C is from the first camp.

A good language to learn on should enforce good practices. A good language for getting shit done shouldn't. I know that unit testing is a good idea in theory, but sometimes I just want to crank out some code and see how it goes.

Re:Perl

[darkwing_bmf]

The code may be technically correct but if it is hard to read it will also be hard to update in a safe and efficient manner. If you think code never has to be updated then you haven't been working in software long.

Re:Perl

[darkwing_bmf]

You can have all the innovation you want, but innovation isn't enhanced by allowing you to confuse meters with feet or by allowing you to divide by zero. Certain thing should always be forbidden if they can be detected by the compiler and the compiler can be helped by language rules amenable to correctness. This doesn't limit innovation it just minimizes obvious (or not) flaws.

Re:Perl

[budgenator]

just use English;!

Re:Perl

[SpaceBuggy]

Take the semicoln in C. It's not needed. It's really just a pleasant confirmation to the compiler to let it know that your current statement is done.

It certainly is needed, if you want to keep white space insignificant. C compilers can skip over every space, tab, and line break that isn't part of a string. Getting rid of semicolons would needlessly complicate lexical analysis.

Re:Perl

[jonnyj]

I've never used Perl, but the parent makes a very good point. Why move unless you have a problem?

This topic is already full of fanboys touting thir favourite tool, but one man's meat is another's poison. You already know the options (Perl, Java, PHP, Python, C#, etc) - if you don't, you're not ready to make a decision yet - so what you really need is a decision-making process.

List out all of the things that might matter to you: team skills, staff availability, platform dependence, maturity of platform, speed of development, ease of maintenace, cost, execution speed, availability of hosting, etc. You should know what those things are; if you don't you're not yet ready to make a decision. Give each attribute a weighting from 1-5 that reflects your business priorities.

Now score each language against each attribute. Sometimes you'll have to guess, but that's not going to be too much of a problem. 1-5 is a good scale; anything else will be spurious accuracy.

Now total the scores and weight them. Keep the top 3 options and look at them more closely. Was your scoring accurate? Do you trust the result? This is where your professional judgement takes over: a scoring model can only get you so far.

Do this, and you'll find out what _you_ really need, and not what some random guy on /. thinks is good for you.

Re:Perl

[Sarten-X]

Excellent! You seem to understand my main goal.

Now just find a perfect way to codify "hard to read" in a way that all algorithms and designs may be encoded in a way that is not "hard to read".

Re:Perl

[vux984]

It seems the "modern" way is to cripple expression and power

99.999% of code doesn't need or benefit from that expressiveness or power.

The remaining 0.001% can be written in C by geniuses or assembler if C is getting too much in the way, and it can maintained and debugged by those same geniuses. :p

Try looking at the code in a profiler one day,

That's just fucking stupid to cripple your best (coders) because your worst can't keep up!

Military analogy. You don't necessarily want to put your rookies in the same unit as your elite special forces, but the rookies, in whatever role you put them in, will be supporting their actions in some way.

You can't deploy your special forces without considering the more limited capabilities of the rookies supporting their operations. And that can amount to "holding them back" sometimes, so the rest of your forces can "keep up".

Re: Perl

[jd2112]

Agreed, which is why I get really annoyed with Python bigots. My main exposures to python have been trash piles like Anaconda and cowboy crap that is seven layers of libraries to implement and process check that has such poor syntax that it can't even fail, no matter how screwed the process.

I've seen incomprehensible junk written in tcl, bash, java, javascript, c, c++, visual basic, fortran, cobol, basic and assembler, most often written by "experienced" coders who think comments and structure are anathema and risky to their job security.

Give me "unsophisticated" and/or heavily commented code, thank you.

Personally I can write legible perl, but with vbscript you have the choice of putting 'on error resume next' at the beginning and hoping for the best, or a crapload of error handling code for every function turning a fairly simple program into a steaming pile of spaghetti with shitballs. I am sooooo thankful that Powershell against all odds happened to escape from Microsoft Labs (AKA Where Good Ideas Go To Die) giving us a proper native scripting environment for Windows.

Re:Perl

[Pseudonym]

Well if that's your criteria, write everything in Haskell.

Re: Perl

[mr_mischief]

That you think C aids in expressiveness over Perl, Python, Ruby, awk, Go, Swift, Rust, D, C#, Scala, Clojure, or even C++ shows you're talking out the wrong orifice. C is a lot of things, but it is not terribly expressive or high level.

Re:Perl

[putaro]

You know, you can write hard to read code in C as well but most C doesn't turn as hard to read as most Perl.

Unreadable code is unmaintainable code. It may not be buggy but how do you know?

Re:Perl

[bill_mcgonigle]

What's the problem with Perl again?

It's not new enough or buzzy enough.

Re: Perl

[vux984]

That you think C aids in expressiveness over Perl, Python, Ruby, awk, Go, Swift, Rust, D, C#, Scala, Clojure, or even C++ shows you're talking out the wrong orifice

I expect we're using the word "expressive" differently.

C is a lot of things, but it is not terribly expressive or high level.

Definitely not high level.

C lacks concise and easy to use language syntax to express ideas, but almost any idea that can be imagined can be expressed (implemented) in C. That is what I meant by expressive.

Higher level languages provide all sorts of direct language support for ideas that are not directly present in lower level languages, but all high level lanagauges ultimately compile down to machine code, which can be represented by assembler. Therefore, nothing that can be expressed in any language can't be expressed in assembler. Therefore assembler is maximally expressive. Anything else is just a subset of what you can do with assembler.

However there is PLENTY you can do in assembler, that you can't do in any other language, and C, is the lowest level language above assembler, and while there are some things that can be done in assembler that can't be done in C, there's not a lot that can be done in a higher level language than C that can't be done in C.

Not easily. Not concisely. And not safely... because if you implement a reference counting garbage collector in C to do your memory management (and you can) there is nothing in C stopping you from directly manipulating the GC state to achieve all kinds of stuff you can't do in the higher level language ...and should probably never do!! -- but this isn't about *should* -- its about *can*.

Re:Perl

[Bite The Pillow]

You make good points, but the analogy was shitty.

Not just bad, or even *bad*.

It was cum-garglingly, cunt-leakingly, colon-lickingly shitty.

If your (coding) language makes it easier to be sloppy, regardless of whatever additional criteria you have arbitrarily added to the argument, it is not a good choice. All of the fine structure in the world can be written sloppily. Especially in the relatively common case of having a design shipped offshore to be implemented by the cheapest labor.

Being a great writer can be done in any language. Choosing the best one for the job helps average and bad people make fewer mistakes.

And none of this helps answer the question of which language should be used by people writing a "web based service". And for that matter, I don't think anyone can help given that vague description.

So let's just argue semantics and move the goalposts without having any real content to bite into, because that seems like the way this is headed.

Re:Perl

[LWATCDR]

It is not cool and hip.
The real answer is that Perl can be hard to maintain unless you enforce strict programing standards and it is not easy to find really skilled Perl programers. A less than top notch Perl programer means problems down the road for sure.
PHP, Python, and Ruby are all popular choices. PHP probably has the biggest talent base but has many of the same problems as Perl.
Python and Ruby are easier to maintain but harder to find coders for.
 

Re:Perl

[Intron]

man perlref

If you haven't figured out what's wrong with that yet, I question whether you have experience working with any properly designed languages.

I figured out what's wrong. That should be: perldoc perlref

Re:Perl

[Tablizer]

I suspect the first fully mutating and evolving virus will be written in Perl. Resistance is futile.

Re:Perl

[dbIII]

No problem, just read the comment that tells you want it does.
No comments?
Then why blame the language?

Re:Perl

[Half-pint HAL]

Uhuh. And what detail do you want the comments to have? If there are more comments than code, the code isn't clear enough.

Re:Perl

[Half-pint HAL]

Regular expressions may be a bit arcane superficially, but once you know them, you know them, and they're pretty quick to decode.

In a lot of internet debates (ie massive fights) about human-readability of code, a false distinction is made between natural-language-like languages and non-human-readable languages. Regexp is a mini-language that is small, regular and learnable. It's not natural-language-like, but once taught is human readable in the same way a mathematical formula is -- not necessarily instantly comprehensible, but very quick to read.

The argument for mathematical languages has always been the compactness of a formula, and the fact that a formula is a semantic description. The equivalent in normal coding practice is to write out all the steps for performing the formula. Well, an arbitrary sequence of steps, as there are always multiple ways to approach the calculation of any formula with more than two terms.

The natural-language-like language is less readable, because it has less semantic content, hence our need for comments. Formulas are shorter and need far fewer comments. With a regexp, I can name it "US_date_format", and it's documented. Writing a piece of C code to explicitly identify text strings containing dates in the US format would be long and arduous, and individual steps would be isolated, making the overall function of the procedure harder to verify.

Re:Perl

[Krigl]

There are more "hardcore/weird/idiosyncratic/expressive/niche/unintelligible" languages for geniuses than just C, I've just recently ran into this nice 18 byte cunt-generating tidbit:

' *'{~4=+/~ 4<.|i:5

Ha, got "Filter error: Please use fewer 'junk' characters.", when trying to post both code and result, Slashdot apparently can't stomach rhombus made of asterisks, thus inadvertently giving unplanned example of expression and power being too limited for something relatively simple, yet unexpected. Unless it's just protection from pasting heaps of ASCII art?
Anyway, result's here, proper Slavic cunt symbol should have vertical line in the center, but the shape is generally recognized as simplified substitute, as in, say, Renault logo ("One cunt on the grill, the other behind the wheel." as somebody mean, probably me, remarked when homeroom teacher passed us in her car).

Re:Perl

[gbjbaanb]

so you're saying you should only have a language that allows you to code in, say, metric.

For safety, right.

Then what happens when you come across a 3rd party system, written in a different system, that only supports imperial. This is why having the flexibility is a benefit.

You can't fix stupid, so don't try to straitjacket everyone just because some people cannot code or design properly.

Re:Perl

[darkwing_bmf]

In some languages you can create your own types. So you can have a variable A that is type meters and B of type feet. If you try to assign A to B or vice versa without explicitly typecasting (letting the compiler know you intended to do this, which comes in handy in conversion functions), the compiler will produce an error. It's a safety mechanism. You're not forced to use this feature but if you do it can help.

Re:Perl

[david_thornley]

The C language does have significant white space, particularly in the preprocessor stage.

Re: Perl

[HeckRuler]

Whoahohold on there buddy, let me fix that for you

but almost any idea that can be imagined can be expressed (implemented) in any Turing complete language.

When people talk about "expressiveness" they usually refer to how easy it is to express such thoughts, not if it's possible.

Anything else is just a subset of what you can do with assembler.

No, actually, that's not true. You see, anything any Turing complete language can do, can be done by any other Turing complete language... eventually. The actions are 100% translatable. It might take you a whole boat-load of code to replicate objects in C, but it can be done. And sometimes that a Turing Tarpit.

some things that can be done in assembler that can't be done in C

Not conceptually. I mean, sure, you can do things faster in assembly, using less opcodes, just as you can do things faster in C, using less lines of code. But if you want result X, C can get you result X.

Not easily. Not concisely. And not safely

And here's the crux of the argument. That C is harder, less concise, and not as "safe" as other languages. Now, I love C. I'd even say that it's the best language to tackling serious problems. But for web-dev? For "expressiveness"? No man, no. I have to disagree. C is unsafe as all get out. It let's you shoot yourself right in the foot. We don't need no stinkin' safties! C can do anything, but it takes a lot of work to wrangle it into shape. Have you looked at the GTK? You CAN make you own garbage collector, but that's a lot of code. And simply put, C is hard. It's not a good language to learn on.

Re:Perl

[MikeBabcock]

People will find a way ... http://c2.com/cgi/wiki?Obfusca...

Re: Perl

[mr_mischief]

Turing complete != expressive

Re:Perl

[HeckRuler]

It certainly is needed, if you want to keep white space insignificant.

Huh? Have you ever written a compiler? A C compiler could infer the end of statements, regardless of semicolons or whitespace.

Getting rid of semicolons would needlessly complicate lexical analysis.

Well, yes, a little. But so what if it's a little harder to make a compiler for the language? That has nearly zero impact on the vast majority of people using the language. I mean, have YOU ever contributed to the GCC?

Or were you talking about coders' ability to read the code?

The response to that would be that new statements should go on another line, what kind of barbarian are you if you don't do that? Whether or not the line ends with a semicolon doesn't especially make anything more readable.

Just take a chunk of C code. Now delete all the semi-colons. Is that so much harder to read?

Re: Perl

[vux984]

Turing complete != expressive

Like I said, we were using the word expressive differently.

http://en.wikipedia.org/wiki/E...

It shows two uses, I meant the former, and you meant the latter.
Your not wrong. Neither was I.

Re:Perl

[hoggoth]

> /&%#%^&*)^ADVkjR$%^$E)!HJLGAZ^&R%\jkghlk/^
> Random garbage or valid perl?

I just ran it through my Perl interpreter to find out:

$ perl -e '/&%#%^&*)^ADVkjR$%^$E)!HJLGAZ^&R%\jkghlk/^'
42
$

Re:Perl

[kmoser]

The fault lies neither with Perl, nor even with the programmer's obfuscated code. The fault is lack of documentation and/or comments which explain the code.

Re: Perl

[vux984]

Whoahohold on there buddy, let me fix that for you

It doesn't need "fixing". If you want to expand on the other use of expressive power, by all means, have at it though.

When people talk about "expressiveness" they usually refer to how easy it is to express such thoughts, not if it's possible.

As you said "usually refer to how easy it is to express"... USUALLY
Both are valid. Like I said, I was using the another usage for expressive.

http://en.wikipedia.org/wiki/E...

No, actually, that's not true. You see, anything any Turing complete language can do, can be done by any other Turing complete language... eventually. The actions are 100% translatable

Sorry no. What you wrote isn't wrong in any way, but it isn't really a refutation of my argument either.

Turing completeness just means both languages can simulate a turing machine (subject to normal physical constraints such as having finite memory instead of ininifite tape etc). So in terms of expressing algorithms etc if a turing machine can implement it, then any language that is turing complete can implement it.

Not ALL problems however exist in that abstract problem domain.

High level languages lack the expressive capability to exert precise direct control over the hardware.

You can't write a device driver for a peripheral card in Lisp, because you need memory and port mapped IO, and Lisp lacks the ability to address the hardware directly. (Although I have seen some neat tricks using files mapped to memory, and then using lisp to read and write to the file to control the hardware -- but that layer doing the crucial file-to-memory mapping wasn't written in lisp. Nor were the actual file reading and writing functions. Those are things just can't be done in higher level languages, despite them being turing complete.)

Not conceptually. I mean, sure, you can do things faster in assembly, using less opcodes, just as you can do things faster in C, using less lines of code. But if you want result X, C can get you result X.

Assembler gives you register level control that you don't have in C. If the exact "result X" I want is X in register A, Y in register B, Z in register C, etc... then I may not be able to do that, even in C.

And here's the crux of the argument. That C is harder, less concise, and not as "safe" as other languages.

Agreed.

Now, I love C. I'd even say that it's the best language to tackling serious problems.

I'm not even sure I'd go that far. I'd argue most problems are better solved in something else.

But for web-dev?

Right. C is probably NOT the tool for web-dev.

For "expressiveness"?

And we've come full circle -- I originally meant "expressive power" differently. Using your semantics for expressiveness you'd be right, but that's not was I was talking about.

Re: Perl

[HeckRuler]

Serious problems like avionics, medical software, space-probes, life-support. Critical applications. Where errors and bugs are absolutely unacceptable. Or back-end OS software, or server software where you care about speed of execution.

Not ALL problems however exist in that abstract problem domain.

And this is the bit you're getting wrong. Turing-completeness has deeper ramifications than the ability simulate a Turing machine. It has to do with computability. The question of CAN we describe an algorithm to do X. And it turns out that if you have some basic building blocks like the ability to branch and remember things (and an infinite amount of space to work with), then you can compute anything that any other Turing complete machine could do.

High level languages lack the expressive capability to exert precise direct control over the hardware.
You can't write a device driver for a peripheral card in Lisp, because you need memory and port mapped IO, and Lisp lacks the ability to address the hardware directly.

As does EVERY language. Even Assembly. Microsoft's masm, or yasm are specific programs that know how to map x86 hardware to software, but the exact same thing can be done for a Lisp compiler. You're confusing an implementation of a language with the language itself. I could say that the KEIL51 C compiler gives me special function registers, sfrs, which are mapped to the 8051's serial port. BAM! just the same functionality that the assembler gives. Either you consider that an aspect of the language or you don't, but assembly, C, and Lisp are all in the same boat.

Re:Perl

[AK Marc]

No, he's not. He's confusing ambiguity and obscenity. A good spoken language is like French. Being proscriptive, rather than descriptive, there is much less ambiguity, compared to a mongrel descriptive language like English, where "bad" and "bad" are antonyms, and "hot" and "cold (or cool)" can be synonyms.

A good language would eliminate such ambiguity/conflict, and have the meaning clear for all.

Though French fails for its pronunciation rules, and Russian and Spanish are better for "spoken language" even if French may be a better written spoken language. Though accents manage to screw up Spanish and Russian as well. "y" and "ll" are pronounced the same in Argentina, but not Spain. And "o" sounds like "a" in Moscow, but only when it leads a word that isn't a name (mostly).

Re: Perl

[AK Marc]

C isn't expressive? If I like to code with recursion, in what looks like infinite recursion, with "hidden" termination events, how many of those will let me code in something that the compiler will take as an infinite recursion? I've not programmed in most, but I've done infinite recursion in C. It works fine, even if you have actual infinite recursion and some interesting error handling or have a termination that is not recognized by the compiler.

Re:Perl

[AK Marc]

There are some statements for which the ; is redundant. Function(something,somethingelse); there's nothing valid that can come at the end, other than the ;. So, why require it? Some compilers don't. But only for things which are ambiguous. i=i+1;j=j+2;k=k+3 would become problematic without the semicolons and whitespace.

Re:Perl

[AK Marc]

The code documents what, the comments document why. Why does i=i+1? "loop counter" isn't a long comment, but makes it clear what i is or what the equation is doing. And yes, is more characters than the code.

Re: Perl

[vux984]

Serious problems like avionics, medical software, space-probes, life-support. Critical applications. Where errors and bugs are absolutely unacceptable.

Yes, places where correctness is more important than speed. I would want these written in higher level languages than C as much as possible.

Or back-end OS software, or server software where you care about speed of execution.

Agreed.

And this is the bit you're getting wrong.

I disagree.

Turing-completeness has deeper ramifications than the ability simulate a Turing machine

That is literally the definition of turing completeness.

It has to do with computability. The question of CAN we describe an algorithm to do X. [..]

Yes, yes, I know what computability is. And so do you.

Although I'd clarify that computability theory has to do with the ability to compute X, not "do" X. If I write an algorithm for tying my shoes, that cannot be computed by a turing machine. The calculations for the required movements of the strings can be computed but actually moving them, actually "doing" it, is not.

Computability theory is a mathematical branch, pure and abstract.

Computer languages that are all turing complete may not be able to DO the same things.

You start to address this when you write:

You're confusing an implementation of a language with the language itself.

However the language specification itself talks a great deal about how it MUST be implemented, and it is not entirely accurate to separate the language from an implementation of that language completely.

but the exact same thing can be done for a Lisp compiler.

The difference being that it MUST be done for the C compiler because that is part of the language. With lisp it would be an unofficial extension of lisp that is not lisp, AND implementation dependent.

Really, lisp itself is probably not the best example of what I'm trying to get at. Magic the Gathering is also turing complete. The fact that you can use the rules of Magic the Gathering, with its events, triggers, and using its card copy mechanics and token mechanics to store state and simulate a turing machine is pretty awesome mathematically. And anything you can compute in C or Lisp you can compute in Magic The Gathering.

But you can't use MtG to set a specific pattern of bits in a specific location of memory on a computer.

Magic the Gathering just talks about cards, and phases, and tokens... and sure you could implement it on a computer, in such a way that manipulating the cards and tokens is represented by a specific pattern of bits in specific places -- but that would be entirely implementation dependent.

With C you can rely on being able to to manipulate bits of memory just-so, because the language spec says you have to be able to do it just-so or its not C.

C is not merely a language, with syntax and flow control -- its specification ties it to the hardware, and this gives it ways to control the hardware in ways other languages do not. This is not merely a happy coincidence of the implementation -- this is required by the language spec.

Re:Perl

[Noah Haders]

current comment count is 498. adding two more comments to break 500

Re:Perl

[Noah Haders]

second comment added. yay 500!

Re: Perl

[lsatenstein]

That you think C aids in expressiveness over Perl, Python, Ruby, awk, Go, Swift, Rust, D, C#, Scala, Clojure, or even C++ shows you're talking out the wrong orifice

I expect we're using the word "expressive" differently.

C is a lot of things, but it is not terribly expressive or high level.

Definitely not high level.

C lacks concise and easy to use language syntax to express ideas, but almost any idea that can be imagined can be expressed (implemented) in C. That is what I meant by expressive.

Higher level languages provide all sorts of direct language support for ideas that are not directly present in lower level languages, but all high level lanagauges ultimately compile down to machine code, which can be represented by assembler. Therefore, nothing that can be expressed in any language can't be expressed in assembler. Therefore assembler is maximally expressive. Anything else is just a subset of what you can do with assembler.

However there is PLENTY you can do in assembler, that you can't do in any other language, and C, is the lowest level language above assembler, and while there are some things that can be done in assembler that can't be done in C, there's not a lot that can be done in a higher level language than C that can't be done in C.

Not easily. Not concisely. And not safely... because if you implement a reference counting garbage collector in C to do your memory management (and you can) there is nothing in C stopping you from directly manipulating the GC state to achieve all kinds of stuff you can't do in the higher level language ...and should probably never do!! -- but this isn't about *should* -- its about *can*.

I would program in Ivorson's APL Seed Dialog APL. Its intrepreted, rapid development, and super easy to debug/trace. That was my favourite languages of the 60's and it still is.

I'm sure it could be interfaced to any browser.

Re:Perl

[lsatenstein]

Take the semicoln in C. It's not needed. It's really just a pleasant confirmation to the compiler to let it know that your current statement is done.

It certainly is needed, if you want to keep white space insignificant. C compilers can skip over every space, tab, and line break that isn't part of a string. Getting rid of semicolons would needlessly complicate lexical analysis.

Without the semicolon, you would have to rely on indentation. Thats turning C into Python.

Re:Perl

[ale2011]

Now just find a perfect way to codify "hard to read" in a way that all algorithms and designs may be encoded in a way that is not "hard to read".

Each language codifies how it works. When the emphasis is on DWIM, a language if favoring writing over reading. Perl is better at roughing out utilities than coding highly maintainable systems, by language design.

Re:Perl

[gbjbaanb]

fair point, but if we got rid of the "richness" of a language we would lose a lot more.

Nobody ever made a joke in Esperanto for example, yet the very internally inconsistent English gives us the greatest literature and humour there ever was.

Maybe the problem lies with us then, to express ourselves in ways that are clear and unambiguous when needed (which is certainly possible) without turning ourselves into robots.

That said, if we did want a programming language that was as clear as he wanted, none of the incumbents are good enough. It would have to based on mathematics to be exact, and then.. everyone would complain that it was too difficult to code in.

Re:Perl

[AK Marc]

Nobody ever made a joke in Esperanto for example, yet the very internally inconsistent English gives us the greatest literature and humour there ever was.

Says someone who has never heard Shakespeare in the original Klingon.

It would have to based on mathematics to be exact, and then.. everyone would complain that it was too difficult to code in.

You can always code in machine code, or if that's too annoying Assembly. But that's not very portable, so higher languages were made to abstract the source code from the machine code.

Maybe the problem lies with us then, to express ourselves in ways that are clear and unambiguous when needed (which is certainly possible) without turning ourselves into robots.

Every language has jokes. Even the proscriptive ones. It can be hard to be unambiguous in English. It's too easy for something to have an unintended meaning, when the meaning is in the eye of the beholder.

Re:Perl

[gbjbaanb]

I've heard Shakespeare in the original brummy though - mostly at school :)

All languages can be unambiguous, however terse and unambiguous is not generally possible. So all the coders who want to write a couple of characters will be disappointed if they have to explain what they want in terms that make it very clear.

I thought assembly might be compared to a math style language, maybe it is. Maybe that's what we need more of- clear, simple, exactly defined instructions. Its when we start to build on that and make routines and "ease of use features that things start to get fuzzy.

Or how about small libraries. I compare Linux to Windows and we all know Linux is much easier to administer (from a serious, PoV, not cheap and easy to click things), the reason is that its built from a lot fo small components that do 1 simple thing. Then its easier to build a bigger solution from these bricks. The interdependancy isn't built into them, like Windows which can be nasty sometimes.

Maybe a language like lego is the ideal programming then!

Re:Perl

[eriqk]

man perlref

$man perlref
No manual entry for perlref

Re:Perl

[HeckRuler]

Not the best example, but you managed to point out what the problem is.

Here we go:
  i=i+1;j=j+2;k=k+3

If we simply remove the semicolons:
  i=i+1j=j+2k=k+3

Then we have variable names starting with numbers which is invalid.

If we replace the semicolons with spaces, then the compiler can infer the end of a statement, and everything is peachy. AH, but the complaint is that whitespace is now significant. But let's look at an example that doesn't run afoul of the "numbers starting variable names" issue:

i=i+foo;j=j+bar;k=k+var

If we remove the semicolons we get:

i=i+fooj=j+bark=k+var

fooj and bark are not the variables you intended. And that could cause problems. For everything else in C, the variable names are going to have some sort of operator or symbol or whatnot on either side of them.

Hmmm. But you sill need a space between void and main(), and any other such keyword. So I'm not sure you can say that whitespace is insignificant in C. But getting rid of the semicolons would make whitespace more significant.

Re: Perl

[HeckRuler]

C is not merely a language, with syntax and flow control -- its specification ties it to the hardware

What hardware? I mean, ANSI C, C99, and C11 don't lay out the X86 i/o map nor tell the compilers how to talk to ARM chips or MSP430's. What spec are you talking about?

I'm not sure you can claim "unofficial extensions" to Lisp are disqualified while saying C is more than it's spec.

I'm just saying, if you can do it in one language, you can do it in any other. As long as they're all turing complete. You seem to put assembly and C on some sort of pedestal. I'm just pointing out that the pedestal isn't real. There are so many better reasons to praise C, use one of those.

Re:Perl

[AK Marc]

I thought assembly might be compared to a math style language, maybe it is. Maybe that's what we need more of- clear, simple, exactly defined instructions. Its when we start to build on that and make routines and "ease of use features that things start to get fuzzy.

Assembly is grouping of machine code, transliterated into English sounding commands. The most common I can think of (I haven't used it in a while) are 1:1 with machine code, not like a "for" loop in a high level language that could have multiple instructions under it, and depending on the language, the same command might map to different machine code. In machine code, there's nothing that can be said that you can't say. As you move up, there are more things you can't say.

Or how about small libraries.

How about large libraries. Using large libraries and a "low" language lets you do more. The problem was that with C, there wasn't a single benevolent dictator like there was with Linux, of less-benevolent dictator with Windows to guide and steer the community to effective libraries. There are basic libraries, but not piles of advanced libraries. If the libraries were expanded and updated as the use of the language changed, the language would have evolved without changing, like Modern English. Lest ye be confused, word use has changed, but grammar hasn't and word use was mainly a 1:1.

I think that if C had a benevolent dictator, and was "updated" with libraries that reflected usage, we'd have half the number of languages we have now.

Re:Perl

[AK Marc]

fooj and bark are not the variables you intended. And that could cause problems.

Makes me think of Chinese. In Pinyin, you "mesh" the phonetic representation of the characters together. So you end up with a "word" like "Diànhuà" Going the other way, you have two "variables" combined. You have to separate them. A compiler (for Chinese, the human brain) will recognize foo and j as separate variables because any other separation would be invalid. Unless it's not, in which case the programmer made an error. Ambiguity is only allowed when ambiguity is not allowed. I can't think of a good example in Chinese, I don't know Chinese, but I remember seeing cases where the first N and N+1 characters were both valid "words" but the second character wasn't valid for both cases. At least Chinese is moderately proscriptive, so it'll be checked for ambiguity as new words are added. Nobody checks the programmers variables to ensure it isn't fooj barked all up.

Re:Perl

[HeckRuler]

riiiiiiiiight, but that's not what they're talking about when they say that removing the semi-colon would make white-space significant.

Re:Perl

[gbjbaanb]

Not necessarily required - perl doesn't need the dictator to put all the library code in the language, instead you have CPan.

I agree a common library for C would be awesome. Think of all the linked lists that are created every project :( I think this is one reason why C++ is more heavily used than C - even if you just write C code, you get to use the STL.

Maybe there's the opportunity for a website here... any VCs about want to spend their money on something really useful to humanity?!!?!

Re:Perl

[AK Marc]

any VCs about want to spend their money on something really useful to humanity?

If they wanted to do that, they wouldn't be vulture capitalists.

Re:Perl

[gbjbaanb]

we could dress it up as some social coding bollocks and they'd never realise until it was too late.

Re: Perl

[LWATCDR]

Because.
1. Yes it is a language.
2. A lot more people know PHP well than know Perl well. Notice that I said that PHP has many of the same proble,s as Perl but also has a larger base of programers

Re: Perl

[anotheroddball]

there's no correlation between profanity and bad code, this is a pointless thing to say. A good language can have as many cuss words as it's users want, what one hopes for in any kind of language is clear, unambiguous and versatile grammar :)

Re:Perl

[akubot]

Hell yeah to that... every time I hear someone mention Perl I want to vomit... and when I actually have to look at it, I grab a barf bag.

Re: Perl

[mr_mischief]

• regardless of ease (theoretical expressivity)
• concisely and readily (practical expressivity)

• The first sense dominates in areas of mathematics and logic that deal with the formal description of languages and their meaning, such as formal language theory, mathematical logic and process algebra.[2]

  In informal discussions, the term often refers to the second sense, or to both. This is often the case when discussing programming languages.[3] Efforts have been made to formalize these informal uses of the term.[4]

Yes, both can be useful definitions. When discussing comparative expressiveness of two Turing-complete languages the second holds more meaning. Being Turing-complete means they are equivalent in the first meaning.

Better yet...

[OpenSourced]

Which editor should we use?

Re:Better yet...

[Anonymous Coward]

Anyone but Timothy.

Re:Better yet...

[tbuddy]

+9001 Funny.

Re:Better yet...

[ArcadeMan]

But... but... it's over 9000!

Re:Better yet...

[Pseudonym]

Perl.

Re:Better yet...

[Tablizer]

Vimacs; compromise, people.

Re:Better yet...

[pegdhcp]

Eclipse is a very good IDE as far as IDEs go. If you do not like integrated environments, pico is the best editor I have ever used, extremely simple and very un-talented, but it is fast and reliable, easy to learn and use. Lack of options is a blessing if you are -like me- a sloppy typist and could generate random CTRL sequences etc. as they are not translated into esoteric commands (like that happens in EMACS for example).

Perl still works, and PHP is fine

[ShaunC]

Perl may be legacy to an extent, but it's a Swiss army knife that will get any job done. I don't see it going away anytime soon.

I know it's in vogue to hate on PHP, but PHP is relatively modern, robust, and fully capable of handling enterprise tasks. It's widely adopted and there's support everywhere. Probably half of the websites and services you use every day are built on PHP, it's certainly not the worst language you could choose.

Re:Perl still works, and PHP is fine

[xmousex]

If you are concerned about getting in employees who know the language from school or have experience at several prior jobs, and come in at affordable rates, or have a concern about available contractors, PHP is going to give you a larger available talent pool that you can swap people in and out faster then continuing with perl or going down just about any other path where the knowledge pool will be fairly limited. There are a lot of platforms in PHP that can aid with this, providing frameworks that everyone can follow regardless of how stable or unstable your development team may be.

Re:Perl still works, and PHP is fine

[tigersha]

> PHP is relatively modern, robust

No it isn't

Re:Perl still works, and PHP is fine

[Vellmont]

Anyone cosidering PHP should read this the now infamouns "PHP is a fractal of bad design".

http://eev.ee/blog/2012/04/09/...

Re:Perl still works, and PHP is fine

[RabidReindeer]

PHP was expressly designed to display web pages. Originally the acronym meant something like "Personal Home Pages".

Yes, it has warts, security issues and the original database services were anything but plug-compatible, but it's a great language for quick-and-dirty.

If you want something architecturally cleaner, if not necessarily more secure, there's Python.

Perl has certainly done yeoman service on the web. Its main faults are that it is infamously "write-only" and that - as in the case of sed commands - if you sneeze while typing, you'll have created a valid program. Probably one that does something horrible.

Re:Perl still works, and PHP is fine

[Anonymous Coward]

Sure, on paper it looks like you'll have a large number of viable candidates, but when you start interviewing you learn that the PHP "talent pool" is mostly just a pool.

It's just as quick to hire a real developer and train them in PHP.

Re:Perl still works, and PHP is fine

[TheRaven64]

That's the same logic people used for choosing C, and just past the 25th anniversary of the first remote exploit of a buffer overflow vulnerability, it's still top of the list of causes of CVEs.

Re:Perl still works, and PHP is fine

[Mordok-DestroyerOfWo]

> PHP is relatively modern, robust

No it isn't

Skillfully refuted!

Re:Perl still works, and PHP is fine

[alex67500]

PHP is relatively modern, robust

No it isn't

Thanks for your valuable contribution.

Judging by the fact that most of Facebook is based on PHP, it sounds to me like it's pretty robust... It's also object oriented. The only drawback that I would find as a code-geek is weak typing, but that's a personal opinion, not a lacking feature.

Re:Perl still works, and PHP is fine

[lucm]

Anyone cosidering PHP should read this the now infamouns "PHP is a fractal of bad design".

http://eev.ee/blog/2012/04/09/...

Most of it applies to old, obsolete versions of PHP. That's like complaining about the 640K barrier in Microsoft's operating systems.

Re:Perl still works, and PHP is fine

[lucm]

PHP was expressly designed to display web pages. Originally the acronym meant something like "Personal Home Pages".

Yes, it has warts, security issues and the original database services were anything but plug-compatible, but it's a great language for quick-and-dirty.

If you want something architecturally cleaner, if not necessarily more secure, there's Python.

Could you care to explain how a language is "architecturally cleaner" for web applications when it does not have native web-related features? Unless you consider that piling up frameworks is a better architecture because it brings more moving parts in the picture. Hopefully you are not an architect.

Re:Perl still works, and PHP is fine

[Nemyst]

It's an interesting list of issues, but all it does is whine. If you actually look around for web languages that are widely supported and easy enough to get running, even on cheap shared hosting, you'll find that your choices are extremely limited. PHP, sometimes Ruby on Rails, that's about it. Before you dismiss shared hosting off hand, remember that not everyone has a lot of money to spend on a website, and that a language's widespread adoption DOES factor in the decision to use it.

Re:Perl still works, and PHP is fine

[tepples]

Most of it applies to old, obsolete versions of PHP.

Which might be the only versions that your hosting provider offers because upgrading PHP would change the language's semantics in ways that break other subscribers' programs.

Re:Perl still works, and PHP is fine

[itzly]

That's not an argument. An argument is a connected series of statements intended to establish a proposition.

Re:Perl still works, and PHP is fine

[MightyMartian]

How about is awful and inconsistent library?

Re:Perl still works, and PHP is fine

[danudwary]

No it isn't.

Re:Perl still works, and PHP is fine

[viperidaenz]

They also wrote their own JIT PHP VM

Re:Perl still works, and PHP is fine

[wonkey_monkey]

Wabbit season!

Re:Perl still works, and PHP is fine

[Anonymous Coward]

Why are you letting your hosting provider choose your language? Just get a VPS.

Re:Perl still works, and PHP is fine

[gaudior]

Excuse me, but is this just 5 minutes, or the full half-hour?

Re:Perl still works, and PHP is fine

[BiggoronSword]

PHP is OK. Zend Framework makes it great. Even if you don't use the framework in your application, reviewing the library alone gives great insight into how PHP is supposed to be written.

Re:Perl still works, and PHP is fine

[ttucker]

PHP is relatively modern, robust

No it isn't

Thanks for your valuable contribution.

Judging by the fact that most of Facebook is based on PHP, it sounds to me like it's pretty robust... It's also object oriented. The only drawback that I would find as a code-geek is weak typing, but that's a personal opinion, not a lacking feature.

Besides that Facebook isn't. They use a proprietary solution that started with PHP, but is really something else now.

Re:Perl still works, and PHP is fine

[Anonymous Coward]

Sarcastically rejoined!

Re:Perl still works, and PHP is fine

[meustrus]

Don't piss on Javascript. Sure, the standard library is terrible and poor cross compatibility makes it impossible to do anything interesting in a browser without shims, but purely as a language the whole "class = function = object" idea is truly magnificent in its own way, especially with the implementation of anonymous functions and closures. The ability to override "this" as well provides many useful metaprogramming tools; just recently I used it to load an external library into its own independent global scope (since it is not well behaved and I don't want it messing with the existing global scope). I always find pleasure writing Javascript when the task is narrow enough and I've got everything I need. And just so you know I have used C, C++, C#, Java, Ruby, Lisp (Scheme), PHP, and Javascript.

(more on-topic, I can't speak towards Perl, but PHP can be done right and when it is it can be maintained by anyone, although most of "anyone" will probably write you a horrible kludgy mess instead)

Re:Perl still works, and PHP is fine

[ttucker]

And your insightful comment gave us exactly 0 examples of problems with PHP. If you're going to hate on it, give us a reason.

Tight coupling with database drivers seems to be a recurring theme in PHP, as one example.

Re:Perl still works, and PHP is fine

[Tablizer]

That's like complaining about the 640K barrier in Microsoft's operating systems.

Yeah, who the hell needs more than that?

Re:Perl still works, and PHP is fine

[93 Escort Wagon]

Yes, it has warts, security issues and the original database services were anything but plug-compatible, but it's a great language for quick-and-dirty.

Yes, let's gloss over PHP's security issues. I mean, It's not like the developers ever broke crypt and then debated whether or not they were going to fix it...

Re:Perl still works, and PHP is fine

[MikeBabcock]

Better ... http://blog.codinghorror.com/p...

Re:Perl still works, and PHP is fine

[Dynedain]

Until they start developing widgetFactoryFactoryFactoryFactory structures. I'm not exagerating. I've seen a senior developer/architect with a Java app build a PHP system that way, while spending every free moment bitching about how bad PHP is.

Re:Perl still works, and PHP is fine

[MikeBabcock]

Interesting response: http://blog.codinghorror.com/p...

Although personally I still avoid PHP whenever possible.

Re:Perl still works, and PHP is fine

[ArhcAngel]

Well it made for one hell of a funny 5 minutes on Monty Python

Re:Perl still works, and PHP is fine

[RyuuzakiTetsuya]

hiphop/hack might not be pure PHP but if you're a PHP programmer, you can figure out and pick up hiphop and/or hack.

Re:Perl still works, and PHP is fine

[xmousex]

you seemed to skip over the

" and come in at affordable rates, "

part of the post.

Our current platform has grown just fine over the last nine years and the perl platform we were on prior to this one began to have issues with finding new blood willing to come in and support it. The old blood wanting more money were typically snatched up by large corporations who would afford them.

Re:Perl still works, and PHP is fine

[Jesus_666]

PHP is the boring, reliable choice. It's popular enough that it's probably still going to be mainstream in twenty years. The ease of entry means a steady stream of neophytes who end up checking out PHP at their first web language.

It's not a pretty language but you can be reasonably certain that for the forseeable future it's going to stay. It's nowhere near as nice as Ruby on Rails or Python/Django but it does have a huge market share so there's both relatively many people who speak it and a lot of ready-to-use code, from snippets to frameworks.

The huge amount of available code is a bit of a mixed bag, though - PHP attracts a lot of entry-level coders and in many cases it shows. On the one hand you have things like Twig (a clone of Django's template engine) that are a delight to work with; on the other hand you have things like most WordPress plugins, which consist of barely-working code written by someone who thinks that "model-view-controller" involves Kate Moss staring at a gamepad. The fact that PHP makes it easy to write code that is wrong but still runs doesn't help here.

PHP has flaws. A lot of them. It's a pretty annoying language to work with. But it's not going to fade away anytime soon and that is its strength. If that makes it desirable to you then PHP is a reasonable choice. If it doesn't you might want to stay with Perl or take a look at trendier languages like Ruby, Python or JavaScript.

Re:Perl still works, and PHP is fine

[gbjbaanb]

erm... you mean support like this. LTS for 5 years, could be worse.

Re:Perl still works, and PHP is fine

[lucm]

Most of it applies to old, obsolete versions of PHP.

Which might be the only versions that your hosting provider offers because upgrading PHP would change the language's semantics in ways that break other subscribers' programs.

Bullshit. Please post a list of hosting providers that offer only PHP4.

Because here is what 30 seconds of googling show:

Bluehost: PHP 5.4
WebhostingPad: PHP 5.4
Hostgator: PHP 5.4

The old crap in the linked article applies mostly to PHP4 or PHP3. Yet PHP5 has been initially released more than 10 years ago.

Find some other dead horse to beat please, this is getting boring.

Re:Perl still works, and PHP is fine

[lucm]

That's like complaining about the 640K barrier in Microsoft's operating systems.

Yeah, who the hell needs more than that?

You know what is hilarious, it's that with mobile development all the old limits are coming back. The other day I was reading the story behind vi and the fact that using short one-letter commands was a decision linked to a slow 300-baud network link, and I couldn't help but think about minified javascript...

I have no experience with wearable computers (watches, glasses, etc.) but it must be even worse on those devices.

Re:Perl still works, and PHP is fine

[GeekBird]

So, basically, you're cheap and only wanting to hire young kids with no experience. You get what you pay for.

You aren't willing to pay experts, but you are willing to pay a bunch of noobs with "new" "hip" "modern" language skilz to recode your entire platform. So you are not only cheap, but penny wise, pound foolish.

Re:Perl still works, and PHP is fine

[fhic]

Don't piss on Javascript. Sure, the standard library is terrible and poor cross compatibility makes it impossible to do anything interesting in a browser without shims, but

Maybe it's just me, but I find this hilarious. "but"...

I dread being handed someone else's Javascript code. It's nearly always faster for me to refactor it than to try and resolve a subtle bug.

From what I read here on Slashdot, I thank the gods that I don't do Perl. And many of the complaints I read about PHP are surely valid, but I like it and use it anyway, and so far I have not shot myself in the foot.

Re:Perl still works, and PHP is fine

[xmousex]

We do have two experts on staff long term that maintain the core, but yeah new people come in and get started with us all the time and it works out great. They add to our platform as need and eventually move on, and PHP is a decent platform for this model to work. Why do you think this is somehow wrong? Are you too old and get cant a job now and need to cry about it somewhere? This discussion is about what works as an alternative to perl. PHP is working great for our situation.

Re:Perl still works, and PHP is fine

[sound vision]

If your host doesn't allow multiple versions of PHP to be chosen at will, you have a shitty hosting company. I worked at a web host until recently - they were a shitty host but we still had PHP 5.2 through 5.5 available (inclusive). We may even have had older stuff available but I never got asked about it. And, this was on the shared servers. If you were on a dedicated server or VPS, you could of course run whatever version you want. We'd even install it for you if your devs weren't competent enough.

Re:Perl still works, and PHP is fine

[UnderCoverPenguin]

I know it's in vogue to hate on PHP,

I don't hate PHP. I just don't use it unless I have to.

but PHP is relatively modern, robust, and fully capable of handling enterprise tasks.

I'm not sure what you mean by "relatively modern". If you mean it is younger then Perl, that is true. 20 years old vs Perl's 26 years.

Both languages have evolved, adopting new ideas and adapting to new needs. They both borrow from other languages and from each other. Indeed PHP started out as a set of Perl scripts. A side effect of this was that PHP 1.0 (released in 1995) "syntax resembled that of Perl" (http://en.wikipedia.org/wiki/PHP).

Both are "fully capable of handling enterprise tasks".

The original posting claimed Perl "just seems to be ossifying". I think this is a perception problem unwittingly caused by the Perl 6 project. I think what we call Perl 5.20 might have been Perl 7.x (or even 8.x or higher) if the developers were free to increment the 5. As a similar example, look at FireFox and Chrome. Google's use of a single version number created a perception that FireFox 3.x was ancient. After Mozilla switched to using single number version for FireFox, the perception of FireFox began to improve. Another example: When Intel added "MMX extensions" to Pentium, people asked when will PowerPC get MMX extensions. The fact that the PowerPC already had equivalent features was ignored and the PowerPC was painted as falling behind the Pentium.

Perl, PHP and many other "old" languages are still used. If anything, their continued use is better evidence to expect they will be actively supported 5 (or more) years from now then whatever the current "rising star" happens to be..

Re:Perl still works, and PHP is fine

[budgenator]

You just have to filter out the people who list HTML as programming.

Re:Perl still works, and PHP is fine

[Clsid]

You are free to use PDO you know

Re:Perl still works, and PHP is fine

[Clsid]

PHP >5.3 is a good foundation and it mostly depends on what you want to do. PHP lends itself to develop something quick that works, like the web prototype language. You can even create a nice n-tier architecture with it, but as far as performance is concerned unless you are using some sort of cache, you are better off with a Java or .NET based solution.

Re:Perl still works, and PHP is fine

[budgenator]

When versioning was a problem, most hosts had multiple versions of PHP so you could choose the one that worked, and if one didn't work it was mostly due to your code being sloppy and using techniques that were depreciated for years prior. Now it's usualy due to your code depending on an insecure settings in the php.ini file and again being depriciated for years.

Re:Perl still works, and PHP is fine

[pak9rabid]

Judging by the fact that most of Facebook is based on PHP, it sounds to me like it's pretty robust... It's also object oriented.

And functional

The only drawback that I would find as a code-geek is weak typing

Which Facebook is addressing with their language Hack, which is heavily based on the PHP language. As a bonus, you also get a language that's built from the ground-up to be fully functional with their HHVM technology. It's an exciting time for PHP.

Re:Perl still works, and PHP is fine

[ttucker]

hiphop/hack might not be pure PHP but if you're a PHP programmer, you can figure out and pick up hiphop and/or hack.

Running on something inspired by PHP is NOT the same thing as running PHP. Don't forget that everything at facebook is loosely coupled using webservices, many different languages being used in the back end, with Something Similar to PHP, but not, mostly running UX stuff.

Re:Perl still works, and PHP is fine

[tepples]

True, InnoDB has been around since I've been using MySQL. But MySQL still doesn't support transactions and full-text search on the same table unless you write your own indexer.

Re:Perl still works, and PHP is fine

[ttucker]

Personally, I never touch PHP.

As a comparison, in the JDBC world, most databases do not even have non-JDBC drivers.... The existence of mysqli is a tribute to a long standing problem with PHP. In reality, development of the MySQL PDO driver started with PHP release 5.3, which was not even three years ago! PDO might be the future of PHP, but it is a pretty shitty defense of the language to this date.

Re: Perl still works, and PHP is fine

[mr_mischief]

I call bullshit. Nowhere in those other languages is there "mysql_ escape_ string" juxtaposed with "mysql_ real_ escape_ string" in the main language namespace.

Re:Perl still works, and PHP is fine

[tepples]

I didn't mean 4; I meant 5.2. PHP 5.3 was a substantial improvement, but it took quite a while after its release for shared hosts to catch up.

Re:Perl still works, and PHP is fine

[narcc]

That's the best you could you manage?

Hell, that's not even a problem with the language!

Re:Perl still works, and PHP is fine

[tepples]

If only the distro on my server at work had 5.6...

Re:Perl still works, and PHP is fine

[Pseudonym]

Don't piss on Javascript.

There's nothing wrong with pissing on Javascript, but it's unfair to mention it in the same breath as PHP. PHP sucks across the board, but Javascript has very specific and identifiable flaws. You can think of Javascript as the living embodiment of Sturgeon's Revelation.

So, for example, Javascript has quite clean variable semantics (borrowed from Scheme, no less!), making it almost a functional language, but then drapes it in an unwieldy function syntax which discourages you from using it as such. Somewhere inside Javascript you can tell that there's a pretty nice scripting language trying desperately to get out. (Hell, membranes are almost elegant.)

I wish that PHP had redeeming features like that. The only thing it ever had going for it was that 15 years ago it had a better Apache binding than any other language, making it the superior choice to CGI.

Re:Perl still works, and PHP is fine

[Pseudonym]

hiphop/hack might not be pure PHP but if you're a PHP programmer, you can figure out and pick up hiphop and/or hack.

Which just goes to show that there's hope for PHP programmers yet.

Re:Perl still works, and PHP is fine

[Pseudonym]

Yet C is still in wide use, and is still useful for endless applications. Its bastard offspring C++ is another "fractal of bad design," but it's everywhere.

I used to make the same complaint about C++ until I seriously used it for something.

Re:Perl still works, and PHP is fine

[ttucker]

Web languages are nothing without their libraries, so the lack of a unified database driver interface (until rather recently) is a noteworthy problem with PHP.

Re:Perl still works, and PHP is fine

[narcc]

A couple points:

"class = function = object"

This is wrong. There are no classes. Yes, they are being introduced in ES6 -- which is sure to be remembered as the biggest mistake ever made, despite the fact that they're essentially sugar. Pretending to be 'like java' with constructor functions and new was obviously a huge mistake. Why double-down?

(To everyone else reading) They're quite controversial. Not only are they unnecessary, but they introduce unnecessary complexity -- with no obvious benefit to compensate. It's pretty well established that prototypal OO is superior to classical OO in every way. It's simpler, requiring users to understand fewer concepts and yet it's still far more 'powerful'. On 'powerful' I'll direct you elsewhere as I'm not interested in arguing this point with the kool-aid drinking OO zealots. Search for something like 'prototypes vs classes'. If you have it, put your ACM DL subscription to good use.

(While I'm complaining. Arrows? => Way to introduce inconsistency, ECMA! )

although most of "anyone" will probably write you a horrible kludgy mess instead

I'd say that this is true for every language. Never judge the quality of a language by the quality of the code you inherit. No language can encourage developers to write 'good' or 'bad' code.

Re:Perl still works, and PHP is fine

[narcc]

Why do you want people to be woefully misinformed?

Re:Perl still works, and PHP is fine

[Bite The Pillow]

Excuse me, but is this just 5 minutes, or the full half-hour?

This is slashdot. You walked past abuse and argument into bolgia ten, where all of the editors have rashes, dropsy, leprosy and consumption.

Re:Perl still works, and PHP is fine

[narcc]

If your host hasn't upgraded PHP in over a decade, it's time to find a new host.

Re:Perl still works, and PHP is fine

[narcc]

8 years ago is 'rather recently'?

I'd change your emphasized "is" to a "was" or even a "was a long time ago".

Re:Perl still works, and PHP is fine

[Tablizer]

You just have to filter out the people who list HTML as programming.

What is it called then? Markupping?

Re:Perl still works, and PHP is fine

[rastos1]

Yes, it is.

Re:Perl still works, and PHP is fine

[Alioth]

I thought PHP meant "Pretty Hopeless Privacy" due to its track record of security flaws...

Re:Perl still works, and PHP is fine

[budgenator]

I didn't mean that as demeaning to people who are truely skilled at HTML and graphic arts and it is something that my brain just isn't innately wired for doing; but there are a lot of diploma mills that will cover PHP, Perl and Apache administration in half a semester and JavaScript and Flash in the other half. People with these "Web Programmer" certificates often mistake themselves for procedural language programers.

Re:Perl still works, and PHP is fine

[mjwalshe]

back in early 95 for BT I looked at the first version of php and described it as a language for COBOL programmers (BT had/has lots of COBOL programmers) who couldn't hack Perl

Re:Perl still works, and PHP is fine

[BlackHawk-666]

Depreciated...

"You keep using that word, I do not think it means what you think it means."

The word you are after is deprecated. The word you are using is generally used to mean a reduction in value over time (ask an accountant), whilst deprecated means...it's on it's death throes right now, stop using it.

Re:Perl still works, and PHP is fine

[david_thornley]

Having used languages with prototype-based OO and class-based OO, I'm going to decisively say that some things are better done with prototypes and other things with classes.

Re:Perl still works, and PHP is fine

[Tablizer]

I consider those "kinds" of programming, not "programming" versus "not programming". I think I understand what point you are trying to make, but I'm not sure English has the right words to say it well and concisely.

Re:Perl still works, and PHP is fine

[mangobrain]

Duck season!

Re: Perl still works, and PHP is fine

[mr_mischief]

PDO is based on the Perl5 DBI which was done the right way the first time. "Deprecated" doesn't mean it's not being used. Once it's actually removed and people are actually using 5.6 in production then PHP will be more consistent.

That's just a small example, though, of the failure to support loadable modules and separate namespaces for so long. PHP historically has been very inconsistent. Future PHP may not be so, but it's not the future yet.

Re:Perl still works, and PHP is fine

[ttucker]

The MySQL PDO driver was not in active development until PHP 5.3. Existing code using proprietary database drivers is not magically fixed by the existence of PDO. I think a lot more respect would be gained by admitting there was a problem, and talking about why PHP will be good to use in the future.

Re:Perl still works, and PHP is fine

[narcc]

PDO was released with PHP 5.1 and available for 5.0 8 years ago.

Your only complaint was address a long time ago. Let it go, man, let it go.

Re:Perl still works, and PHP is fine

[tepples]

One employer has RHEL, and I'll make sure to tell him about Oracle's Yum repo for RHEL. The other has Ubuntu Server 10.04 LTS, whose support is due to end in about 9 months; I need to have my boss help plan an upgrade.

Re:Perl still works, and PHP is fine

[godefroi]

HTML isn't a programming language, it's a text markup (i.e. text formatting) language. SGML is a markup language. OpenGL is an API, not a programming language.

If HTML is a programming language, and creating HTML "pages" is "programming", then aren't you programming as soon as you turn on "reveal codes" in WordPerfect? How about "reveal formatting" in Word? Are you programming now just because you can see the formatting tags as you type text?

Re:Perl still works, and PHP is fine

[budgenator]

Noweb might make some heads explode.

Node.js

[Anonymous Coward]

JavaScript isn't going anywhere, and is nearly required for web development in browsers... so having it on the server side just makes things that much easier. It's not particularly hard to learn... you hire people with JavaScript experience, and they can get spun up on Node.js in a week or so.

Re:Node.js

[TechyImmigrant]

>JavaScript isn't going anywhere, and is nearly required for web development in browsers

I manage fine without it.

Why is it I need Javascript?

Re:Node.js

[pooh666]

I bet you use too.

Re:Node.js

[amicusNYCL]

Why is it I need Javascript?

Because you want or need to use an application that requires it. I assume you're talking generally and not asking anyone to comment on your specific situation without giving any other details about your use patterns or needs.

Re:Node.js

[SQLGuru]

I'd agree for the most part. There are a lot of pretty cool front-end things going on and with Node makes your front-end and back-end language cohesive. Sure, there are plenty of other options, but there is something to be said for having guys who can transition from front to back or back to front.

Re:Node.js

[TechyImmigrant]

Why is it I need Javascript?

Because you want or need to use an application that requires it. I assume you're talking generally and not asking anyone to comment on your specific situation without giving any other details about your use patterns or needs.

Let's be more specific then. What is it that Javascript does that I cannot do with an alternative language just as or more effectively? I don't dispute that you can use it and some can use it well, but I do dispute that anyone 'needs' it.

Re:Node.js

[TechyImmigrant]

>GWT. Write in a compiled type safe language and let the computer generate all the JavaScript for you.

If my job required me to do a lot of web stuff, this would by the way I would choose.
As it is, there's not much call for SystemVerilog coding in web apps.

Re:Node.js

[WilCompute]

For the next 5 Years? Typescript. Typescript runs on node.js, IS Javascript, the next ECMA version of it at least, and is supported by Microsoft, so it will be supported for at least 5 Years. Since it is the next version of Javascript, It compiles to all the current browsers, and can be used with current Javascript libraries.

If you like Visual Studio, 2013 has first class support for it.

Combining this with, say, Web Components such as Polymer from Google, or Bricks from Mozilla, for the front end of your system, will allow you to future proof your application in the one language the web by definition will support.

(I cannot foresee the future, but I BELIEVE that Javascript will stay as part of the web standard, even if the standards committee were ever to decide to add another language, such as Google is hoping for with Dart.)

(I would like to say Dart, but for a large application, it will be harder to find coders that are familiar with it, versus Typescript, which at worst can be written by decent Javascript Developers.)

Re:Node.js

[jbolden]

Javascript executes client side. It is the interpreted language that rendering engines are being built around. You can't have scriptable interactions with low latency without something like it and it is at this point usually the best choice.

Re:Node.js

[amicusNYCL]

What is it that Javascript does that I cannot do with an alternative language just as or more effectively?

If you're asking in the context of a web browser, then Javascript is the only realistic option for a dynamic UI. If you're asking about Node.js on the server, then Javascript support on the server isn't something you can disable in the first place if you're running Node. If you're not running Node, then obviously you don't need Javascript on the server.

Re:Node.js

[mlk]

Run it in a browser without having to compile it into Javascript.

You could o/c not do any front end interaction have a set of static pages (yeay the 90s) or use Flash (Wooo 2000!).

Re:Node.js

[angel'o'sphere]

Unless it is executed on the server, ofc ;D

Re:Node.js

[TechyImmigrant]

Clearly my job looks nothing like yours.

Re:Node.js

[Dynedain]

When building pages to send to the client, there's a lot of value in building DOM structures server-side. Having powerful DOM-manipulation tools is an advantage.

Plus, if you run the same language on both ends, you can start to do some really interesting things, like the Meteor framework, where the same functions exist on both sides of the fence, and work the same way.

Think of the power that exist(ed) in using .NET on both the server and IE. It was proprietary, but made huge advancements in rapid development and deployment.

Node.JS and other JS-on-the-server approaches are making this happen in a OS and browser agnostic way.

Re:Node.js

[Bucky24]

A lot of people still don't see the point to doing this unfortunately enough. Then again, I agree there are places where it is overused.

Re:Node.js

[jbolden]

GP was asking about large unique advantages. Server side Javascript has some interesting potential and possibly some unique features but it isn't the same thing.

If you are saying that server side and client side are equivalent don't forget about latency.

Re:Node.js

[narcc]

The girl at the front desk doesn't need to know javascript either.

So... what was the point of your 'I don't need it' comment? It's not relevant to the 'ask Slashdot' question or the rest of the discussion.

Re:Node.js

[angel'o'sphere]

The latency is the same.
Regardless what you run on either side.

Re:Node.js

[jbolden]

No it isn't. Assume the communication, processing and return from a server take 70 ms. Assume the processing takes only 2ms.

client side: User does X system responds with Y in 2ms
server side User does X system responds with Y in 70ms

That's why google docs for example is usable because it loads the information client side.

Re:Node.js

[angel'o'sphere]

client side: server responses in 2seconds, then the client has to do what ever the server otherwise had, same result, user is now waiting for the client instead for the server.

And bottom line that nothing to do with the question what language to use, except that JavaScript is the only simple alternative on the client, that is also available on the server.

Re:Node.js

[jbolden]

You aren't thinking about the network latency. Your analysis above is wrong.

Re:Node.js

[angel'o'sphere]

I'm thinking exactly about the network latency :) which is in your case higher anyway, at least in the beginning, as you have to ship the *.js libs to the client.

Re:Node.js

[jbolden]

That's a one time cost. You pay the latency with every interaction if you implement the functionality server side.

Think about something like Googledocs without Javascript.

Why not...

[realilskater]

PHP or Java?

PHP has a number of CMS frameworks built in it.
Java has the JavaEE stack.

Avoid Frameworks.

[TechyImmigrant]

If you're using a high level language with WSGI for efficiency, then you can choose the one that meets your performance/complexity goals.

Friendly, maintainable, not high performance: Python
Higher performing, C, C++
Supports elegant solutions if your brains are wired differently: Haskell

But unless your code is a mess, there's nothing so valuable as a large codebase of working code with institutional knowledge built around it. That would be PERL.

Re:Avoid Frameworks.

[Nemyst]

I take it you've missed the "web" part of the question. Writing web stuff in C/C++ is already all sorts of horrible, but Haskell? There's a special place in hell for people like that.

Re:Avoid Frameworks.

[Anonymous Coward]

A lot of people do pretty well using Microsoft .net for web development.

A lot of people do pretty well sucking cock for a living, but I think Perl isn't quite that bad.

Re:Avoid Frameworks.

[TechyImmigrant]

I've yet to meet a Framework that makes things as clean and usable as they claim.

And worse, once a web site is in Django or Drupal or somesuch, no novice can edit anything. Template languages are great if you understand the inheritance model, but non techies do not understand those things. They give up, load dreamweaver and mess all over your lovely framework, so they can get content up.

If you have a staff online to support a web site, then fine. They can mediate transactions. But Frameworks are like an arse. They only get bigger with time.

There are better ways borne of thinking hard about fitting the right solution to the problem.

Re:Avoid Frameworks.

[TechyImmigrant]

Whatever floats your boat.

I see people around here who not only use, but appear to like Javascript. Those people occupy a different mental space to the one I do.

Re:Avoid Frameworks.

[Patman64]

People look at posts like yours and get it through their head that if they use Python, their website will crawl. Nothing could be farther from the truth.

If your website is anything like the majority of websites, the server-side code will spend far, far more time waiting for IO than doing any sort of processing. The language choice is almost irrelevant. It's essentially just glue to join HTTP queries and database queries.

OTOH, if you do need to do some actual processing, you might be better off just doing that in a compiled language (C, Rust, etc.) and using the web framework glue to hook it up to the web.

TL;DR: Using C++ for web server-side because "it's fast" is premature optimization. Don't prematurely optimize.

Re:Avoid Frameworks.

[TechyImmigrant]

>TL;DR: Using C++ for web server-side because "it's fast" is premature optimization. Don't prematurely optimize.

You should know if you're expecting 1Mhit/s or 3 per week.

Re:Avoid Frameworks.

[gbjbaanb]

Don't forget Erlang - designed for uptime.

Personally, I think the C++ option is still the best, only you write your application tier in it, and access it from a ... well whatever you care to use, web server front end. The point is the serious logic goes in the app tier and the presentation tier can be any old crap you can get a junior to write cheaply.

Re:Avoid Frameworks.

[gbjbaanb]

TBH I think C++ is very overlooked as a web development system. If you're any good with it (ie not some n00b who thinks PHP is the best, or a javascript dev who thinks its the only language there is) then you can do very well in it.

There are many web servers written in C++ that are designed to run the server code as well (often used for embedded systems to provide a GUI, but strangely always get hammered in benchmarks to show how fast they are - maybe its an efficiency thing for small devices, but has a side-effect of being very fast for larger-scale systems).

Sure, there's no built-in code for handling common web use-cases, but there's many a library for everything in C/C++ land.

If not, you can still write a service in C++ and call it from any web serve front-end, that's the way you get scalability and security and everyone should do it (after all those cases of hacked webservers allowing the attacker to dump all passwords from the database - wtf did the web server have any access to the DB server.. oh yeah, lazy architecture choices)

I'd have a look at Mongoose for an example. Trivially easy to code a web site with - I used it to embed a web server in existing code that needed to serve a new GUI.

Re:Avoid Frameworks.

[narcc]

Yes. We took the time to learn the language first. We understand things like closures and anonymous functions and understand the value of prototype-based programming. We know how dynamic typing works because we're not morons. We know how 'this' works and understand that the language would be completely broken if it worked like you think it should.

Yeah, I'd call that a 'different mental space' from yours.

It has flaws, sure, but so does every other language. It's also an incredibly clever and well-designed language. You're obligated to learn it first, of course. I know the syntax looks familiar, but it's not Java or C.

Re:Avoid Frameworks.

[Pseudonym]

I've yet to meet a Framework that makes things as clean and usable as they claim.

Webmachine with OTP.

Re:Avoid Frameworks.

[BlackHawk-666]

Non-techies should stay the fuck away from any website that is not just a collection of HTML, pictures of cats, and flashing text. Would you ask your GP to perform gastric bypass surgery on you? Do you ask your bartender to service your car? Let the people with the right skills handle the skilled work.

Re:Avoid Frameworks.

[BlackHawk-666]

Google's other baby, Go has done quite well in some benchmarks too, despite having a pretty simple / inefficient garbage collector. For those of use who shudder a little at the thought of JS on the server, Go serves a good niche.

Re:Avoid Frameworks.

[TechyImmigrant]

In the frameworks I've played with, that is exactly the promise they make. Set it up in 'our wonderful framework' and users can easily update the content. It's BS.

That is what Ruby is for

[cryingpoet]

Ruby is a great Perl replacement. It generates really nice looking content and is very readable. Do more with it than Perl with spending hours trying to understand some else's "snoopy swearing" code in Perl. Please be sure to look into Rails and Rake as well.

Re:That is what Ruby is for

[MouseTheLuckyDog]

Of the three "scripting languages" I find Ruby to be the nicest with the cleanest syntax, but IO think it's MOP goes way too far and create a whole set of problems.

Re:That is what Ruby is for

[khellendros1984]

Which three scripting languages are you choosing as "the" three?

Re:That is what Ruby is for

[Bill_the_Engineer]

I think the poster may be referring to the three cousins: Perl, Ruby, and Python.

C++ and CppCMS

[Anonymous Coward]

Use C++ and CppCMS: http://cppcms.com/

You get the benefits of a real programming language, not just a toy like Ruby, Perl, JS or Go. The code is checked by the compiler, you can compile it to run just about everywhere, and the compiled binaries are FAST. You don't need 10x or 20x the servers just because you're using an interpreted language that's really fucking slow.

And if you aren't a dumbass, you'll use the Modern C++ way. You will reduce your risk of security holes to a minimum, while getting a very efficient language to program with. Unlike Go, you'll get real OO if you need it, and real support for templates.

C++ is for those serious programmers who want to get real work done, and who don't have time to waste with overhyped crap.

Re:C++ and CppCMS

[Dadoo]

You might want to rethink that: http://www.infoq.com/news/2011...

Re:C++ and CppCMS

[turgid]

And if you aren't a dumbass, you'll use ...

A simpler, more efficient high-level (higher than C++) language that is more expressive with fewer lines of code, less prone to introducing silly bugs caused by human error, and more readable by other programmers.

C++ is for those serious programmers who want to get real work done, and who don't have time to waste with overhyped crap.

C++ is for conformists and trend-followers lacking in enough critical thinking skills of their own to investigate and adopt better tools for the job.

Re:C++ and CppCMS

[turgid]

And C++ supports recursion, immutability, and the other hyped features of functional programming.

Yes, and at this rate, perhaps in another 20 years, it will have caught up with LISP (from the late 1950s).

Re:C++ and CppCMS

[Chris Mattern]

"[Object-oriented programming] is both anti-modular and anti-parallel by its very nature"

This sentence makes no sense to me. What are objects if not modules? And surely one can have independent objects run in parallel.

Re:C++ and CppCMS

[narcc]

When you understand that, you'll be enlightened.

What are objects if not modules?

When you can answer that, you'll be on the path to enlightenment!

And surely one can have independent objects run in parallel.

This is just silly. I'm guessing you're joking here.

Re:C++ and CppCMS

[narcc]

Just to add: If you actually need something like C++, you should probably use C.

To the parent: Linus would like a word with you.

Re:C++ and CppCMS

[Pseudonym]

To be fair, also bitter about pre-ANSI C++ and people who say "C/C++" as if it's a thing, which is understandable.

Re:C++ and CppCMS

[Pseudonym]

Functional programming is just a subset of OO programming.

In exactly the same sense, OO programming is a subset of functional programming. An object is nothing more than a tuple of functions each of which has a hidden parameter.

But then, you seem to think that C++ is an OO language, which makes me wonder if you actually understand Modern C++ (in the Alexandrescu sense) at all.

Re:C++ and CppCMS

[Pseudonym]

Nice try, but CLOS dates from 1988.

Re:C++ and CppCMS

[Pseudonym]

C++ is for conformists and trend-followers lacking in enough critical thinking skills of their own to investigate and adopt better tools for the job.

So you're saying it's perfect for someone who thinks that Perl is ossifying, then?

Re:C++ and CppCMS

[david_thornley]

Yeah, and when is C++ going to catch up with CLOS? I suspect never. (Yeah, I'm a big C++ fan, but let's be realistic here.)

Re:C++ and CppCMS

[david_thornley]

Linus has a habit of referring to things as if his own viewpoint was the only one that mattered. Linux predates C++98 by something like seven years, and it was probably a good thing that Linus didn't use it back then. It's almost certainly a good thing that he didn't change kernel development languages midstream, but nowadays I'd suggest C++ for almost anything C is used for, assuming the availability of tools and decent programmers.

Re:C++ and CppCMS

[narcc]

I wouldn't. Name mangling being a good enough reason for the instances that pop in to my head at the moment.

Re:C++ and CppCMS

[turgid]

Indeed, they're a swivel-eyed loon.

Re:C++ and CppCMS

[Pseudonym]

It's probably fair to say that C++ will never have a standard metaobject protocol. (Though it might get multiple dispatch at some point.)

Ossifying?

[Anonymous Coward]

Do you mean "stable"?

What the fuck is wrong with that?

Your job isn't to use hip new languages, it's to keep the service you run WORKING. For the people who PAY YOU. It's a TOOL for their business.

Ask the people paying your salary if they want you recoding things that work into your language-flavor-of-the-week.

Re:Ossifying?

[NoNonAlphaCharsHere]

Clearly you've never maintained someone else's code. With code maintenance, you're not just climbing into an existing codebase, you're climbing into the author's head. The problem with Perl is it supports rampant schizophrenia and cutseypoo hacks. Trying to refactor someone else's Perl can be like an acid trip down the rabbit hole. I use Perl on occasion, usually for one-offs, but if it take more than about 10 lines, I look for a more appropriate tool, even AWK. And I've sworn a mighty oath to never again work on anyone else's Perl code. Life is too short for that kind of aggravation.

Re:Ossifying?

[hondo77]

Code reviews can help you with that. Your company should try them.

PHP is a very solid choice

[brokenin2]

PHP of old used to make it very easy to write applications with large security holes, but newer versions do a much better job of preventing developer's tendancies to shoot themselves in the foot.

I think it will be a very viable choice for web applications for the next 10 years or more.

There are a number of frameworks written in PHP that are pretty good as well. For my current project though, I've chosen to write a framework that is geared toward exactly what that project needed. I did choose to use an HTML framework to aid in the UI creation and standardization. For my project I chose "Foundation", but there are a lot of other good ones as well.. If your application has a requirement of being mobile device friendly (is there anything that doesn't?) then I would highly recommend a 12 column HTML framework.. If you don't know why a 12 column framework is the way to go, Google it, there are plenty of write ups.

Re:PHP is a very solid choice

[Dracos]

PHP of old used to make it very easy to write applications with large security holes, but newer versions do a much better job of preventing developer's tendancies to shoot themselves in the foot.

If that were true, then fetid garbage like WordPress wouldn't even run on PHP 5.3+, being as its code hasn't changed at all since the days of PHP4.

Globals... globals everywhere...

Re:PHP is a very solid choice

[brokenin2]

Globals have been disabled by default in PHP for a very long time.

"register globals" which allowed post and get parameters to be automatically registered in the global scope was defaulted off a long time ago, and in newer versions of php (5.4+) is not even an option any more. This is historically the feature that got a lot of bad programmers in trouble.

Almost every language has a way for functions to access global scope variables, and PHP is not exception, but to do so now, you have to specify exactly what you're going to access by doing it through _GLOBALS or by calling "global " inside your function.

The default scope for variables is to have no globals, and to direct you toward a more OO programming style. You can still shoot yourself in the foot, just like every other programming language, but you have to at least try a little to do it.

Re:PHP is a very solid choice

[Dynedain]

Foundation is not a server-side or even an web app framework. Neither is Bootstrap.

Both are layout frameworks for HTML and CSS, with a smattering of JS thrown in to make some nice client-side widgets behave consistently. The original post is asking about languages and application frameworks, not layout systems.

Re:PHP is a very solid choice

[brokenin2]

He was asking about languages and frameworks and developing their web application for the future.

If they're redeveloping from scratch in order to future proof things, it's unlikely that they're going to be wanting to produce the exact same HTML that they always have. A framework to help you develop better HTML easier is something they should be considering at the same time.

It would really suck to rebuild your application, get to the end, and then decide it's time to make it more mobile friendly, at which point they realize they have to do another redesign because they didn't think about how their user interfaces were going to break down.

If they need to ask which server side language they should use, then they almost certainly need to have these things pointed out to them as well. If it turns out that they didn't need any of that pointed out to them, then they can easily disregard the extra information.

Stick with Perl

[Anonymous Coward]

The real headscratcher to me is the number of programmers who assume that because a language isn't adding features every couple years it is dead.

Re:Stick with Perl

[GeekBird]

The real headscratcher to me is the number of programmers who assume that because a language isn't adding features every couple years it is dead.

This. I hate working with "new" "elite" languages that every new version that comes out breaks existing code in weird ways. (Python, I'm looking at you.)

I've done maintenance on perl code written by people in love with their own intelligence. It's painful. I've tried it on similar stuff in python (see my breaking with new versions comment above.) It's impossible. I rewrite it in something stable and universal - shell or perl.

.Net / Typescript

[garlicbready]

I work in a medium sized software development company, and we work exclusively with .Net usually Visual Basic
C# is also an option in .Net land, typically with the newer frameworks the differences functionality wise are fairly minor
we started with .Net 2,0 web forms and are now on .Net 4.0, everything is backwards compatible as far as I can tell between frameworks
Another direction would be php, or something more specialised such as Ruby for example

If you want rapid development cycles then having intelisense / auto completion / linq / entity framework is definitely something to look into
these languages are server side, you also may want to consider how much of your website wants to be written in client side languages such as javascript. Personally I'm planning on learning Typescript which is a subscript of javascript, basically easier to write and more class based with intelisense

It all comes down to what kind of functionality you want to put into your web apps, and what your developers feel comfortable with

Re:.Net / Typescript

[Richard_at_work]

WebForms needs to die, not have new users - if you want to go down the route of .Net then at a minimum it needs to be ASP.Net MVC, or you can go for a third party framework like NancyFX. ASP.Net vNext is worth keeping an eye on as well.

Re:.Net / Typescript

[Sowelu]

Honest question as a heavy C# user. Why Visual Basic? What advantage does it give, either in function or practice or even aesthetics, over C#? It seems that they are functionally identical but that C# has the better syntax; clearly there must be some reason VB.NET is still around though. Enlighten me please?

Re:.Net / Typescript

[Richard_at_work]

If you have ever had to debug a webforms page with multiple controls, masterpages and an extremely convoluted page lifecycle, then there is no fucking way you would call MVC more complicated.

Webforms needs to die.

Re:.Net / Typescript

[AaronLS]

There is nothing overkill about MVC. It is far simpler than webforms. Webforms is the one that is overkill. The massive view state object that is serialized with every request, the fact that it tries to emulate windows forms controls with heavy objects and non-HTML tags. You want HTML, use MVC. You want the overkill of webforms controls? MVC is far faster even for simple cases.

I did webforms for even applications ranging from simple to complex for 3 years, and I've been using MVC for almost 3 years now, and I can tell you MVC is far simpler for both cases. Webforms was designed to be familiar to people coming from a Windows Forms background, and that layer that created on top of the simple html/http request/response model of the web is overkill. The viewstate for example is designed to give the programmer the sense that state is continuous through the user's interaction, as if it were a webforms app, to hide the request/response web model from the programmer. But this is overkill and actually makes things more difficult to debug and work around. Having to tweak what goes into viewstate and what doesn't. For those who do it alot it is probably second nature, but it is an unnatural layer of abstraction over how the web works.

Try to do something as simple as a small survey that has a dynamic list of questions. On postback, even though you have no intention of showing the user the form again, in order to capture the user's response you must recreate the entire form, and make sure you do it in just the right event handler in the pipeline. In MVC, all you need is a POCO in the Action method parameter.

Re:.Net / Typescript

[AaronLS]

C# has optional parameters now. Long story short, they resisted adding them because they have the potential to introduce breaking changes across library versions as they are bound at he callsite.

If you looked at job listings C# is by far the majority. I reallize that doesn't prove anything, but I think it's a strong indicator that C# is the more prevalent of the .NET languages.

Re:.Net / Typescript

[garlicbready]

The way I see it historically there were large differences between what you could do with VB.Net and C#
but with each newer framework those differences have become less and less to the point where it's now just a question of syntax
since both compile down to IL anyways

Personally I can write in C / C++ and understand C# if I want to
I just find the syntax easier / quicker to write, my brain is just more in tune with VB .Net rather than C#
although I recognise it can work the other way as well

With C# for example every line needs a terminating semicolon which is something inherited from the old C days (I find that irritating)
with VB .Net it assumes every line is independent, if you want to put mutiple lines of code on one line you can use a colon :, or an underscore to continue a line which in practice just feels to work out better
also if blocks / while blocks / other blocks are a bit more clearly defined with If / End If, While End While rather than curly braces { } for every block type

I see it as just personal preference in terms of syntax at this stage since essentially both are the same framework / to the point you can easily convert one to the other

Ruby/Sinatra

[Unequivocal]

As a greybeard who used to write dynamic gopher sites, I really like to write in Ruby/Sinatra now. It gives me access to lots of nice features (I can install activerecord when I need it) and I can build APIs super quickly and everything in between. And I can get down to the bottom of the network stack pretty easily when I want to. I do miss the Ruby/Rails built-in testing framework, but otherwise haven't looked back since switching from that environment.

Remove the ransom note excuse with Deparse

[ksbraunsdorf]

If you don't like ransom notes (which perl programs may become over time) use this trick: get perl to reformat the code with a this command:

$ perl -MO=Deparse ransom.pl >better.pl

Most of the time that removes the crazy from the script. I just got a large legacy code-base and that little trick made my life much better. If the perl code works, then you are just looking for work to do. Newer is not always better.

Re:Remove the ransom note excuse with Deparse

[bytesex]

I just did your deparse trick on my worst perl script, and it made it *worse*! I must be doing something right.

Re:Remove the ransom note excuse with Deparse

[DoofusOfDeath]

If you don't like ransom notes (which perl programs may become over time)

Wait... I thought Perl was the actual threat.

Re:Remove the ransom note excuse with Deparse

[KingOfBLASH]

He's referring to the fact that because perl coding styles can be so person specific, something programmed in Perl that is mission critical may give a ton of leverage to a programmer you'd rather oust.

Your Watch Works, and You Want To Fix It

[LifesABeach]

What could possibley go wrong with that?

Re:Your Watch Works, and You Want To Fix It

[Bite The Pillow]

Despite the warnings of Joel on Software, a rewrite is a great chance to weed out legacy requirements and functionality.

Sure there is the chance of oversimplifying to the point of introducing bugs, but automated regression/unit tests can compare the old and new code output to make sure the results are at least equivalent (if not the same).

An even more important reason is to be able to throw more warm bodies at a problem. Perl recruiting in that area might be difficult, and choosing something trendy but not overly trendy can ease the hiring burden.

So maybe it's not just the code that's broken. The requirements and developer pool could be the broken parts, and switching languages is just the needed fix.

Perl with Mojolicious

[perplexing.reader]

Very powerful and very flexible, without the heavy lifting of many frameworks. We use on a large ISP as RESTFull Server.

Re:Perl with Mojolicious

[grcumb]

Very powerful and very flexible, without the heavy lifting of many frameworks. We use on a large ISP as RESTFull Server.

Seconded.

Mojolicious is an excellent back-end or middle layer (depending on your data needs), mostly because it removes the need for many of Perl's more infamous convolutions and contortions. With a bit of Bootstrap and/or AngularJS on the front end, you can get a useable online service put together in a very limited amount of time.

Javascript FTW

[MouseTheLuckyDog]

Why because Javascript is proof that you can write a language that is worse then Perl.

Re:obvious

[TechyImmigrant]

>Javascript. Code for input validation

Umm... Javascript in a web page can do nothing for input validation. Anyone can send anything they want to a server.

Python

[Lobo42]

Python strikes the balance for me of being modern enough to not feel like it's constantly breaking, but also old and reliable enough to feel like it has widespread support in terms of libraries and is not going to fall off the map anytime soon.

Re:Python

[scm]

Python/Django is what we chose to replace our aging Perl code. Our biggest problem with Perl is that it's really hard to find qualified programmers who want to work in Perl and are local in the Bay Area.

Re:Python

[GeekBird]

Try hiring people who are over 30.

Re:Python

[GeekBird]

No. Take a look at Anaconda, and then try to tell me Python is readable.

Re: obvious

[TechyImmigrant]

> its distinguishing strengths are few and aesthetic

Aesthetics matter.
http://www.amazon.com/Machine-...

Java

[Neruocomp]

Be careful with frameworks, because as soon as you find yourself having to do things outside of its protective little garden, you might as well give up on the framework. But in terms of long lived, go with Java. It has no buzz or the glory the pretty new things have and thats why its still in wide use in the enterprise.

Re:Java

[Voyager529]

But in terms of long lived, go with Java. It has no buzz or the glory the pretty new things have and thats why its still in wide use in the enterprise.

I'm more of the persuasion that the reason why Java is still in widespread use in the enterprise is because it predates most other solutions and no one wants to pay between five and nine figures to replace the existing system.

Java is getting particularly annoying in that they're try to make the runtime environment more secure...and in doing so, have a tendency to break things to the point where it's a requirement to undo all the new security defaults in order to make the Java stuff actually load. Oracle has indicated that it will soon remove the ability to allow things to run by clicking 'yes/allow/run' to half a dozen warning error messages, which means that the amount of time and effort to make the JRE security requirements happy may eclipse the time saved in using it in the first place. Java is also a nonstarter on mobile devices. Finally, I've had major issues reminiscent of IE6 hell - $SOME_APPLET is only compatible with a particular version of the JRE and it's impossible to upgrade without breaking it, so people are stuck on that particular variant of Java.

Disclaimer: I haven't written a line of code since college. I have, however, had to support Java applets and, without exception, they cause these kinds of problems. I don't care if you use PHP, Perl, Python, Ruby, or .NET...just please...PLEASE spare the support staff the hell of dealing with end user Java sites.

Re:Java

[WuphonsReach]

Java in the web client is dead (so is Silverlight / Flash)... go Javascript / HTML5 if you have to do things on the client. Java on the server side... isn't going away for many decades.

The only downside of Java is that it's rather heavy for "one-of-a-kind" web pages. There's a lot of setup that you have to learn (Maven archtypes help) before you get HTML on the web browser. But as soon as you need something that can scale, talk to disparate systems, support unit testing, etc., it's far better then PHP. PHP just falls apart once you get past a handful of PHP pages.

Re:Java

[Neruocomp]

Maybe because I'm a sysadmin I was mainly thing of the backend. With a stable backend, you could put whatever window dressing on top of it according to the flavor of the day.

Do it in C

[cyberspittle]

Time to put on the DeVo and Whip It. Whip it good.

Perl says your garbage is just that

[Anonymous Coward]

Well, it says it in it's own polite way:

$ perl -e '/&%#%^&*)^ADVkjR$%^$E)!HJLGAZ^&R%\jkghlk/^ && print "Valid? No way!"'
syntax error at -e line 1, near "^ &&"
Execution of -e aborted due to compilation errors.

Re:Perl says your garbage is just that

[wed128]

He did. look at the end of the line.

Re:Perl says your garbage is just that

[lsllll]

syntax error at -e line 1, near "^ &&"

Hell, at least it made it 2/3 of the way through.

No good answer

[discord5]

today's rising star could quite easily be in tomorrow's dustbin

Well, at some point Perl was a rising star...

No matter what you're going to pick, it won't stand the test of time in the end.

• Perl? Dead, done for, the perl community invited to the funeral but the refused to come since they were too busy organizing their next YAPC and having fun.
• PHP? Waiting to be killed off. CVE-2015-0001 will classify the entire PHP codebase as exploitable, and in a desperate attempt to fix things, the developers will just delete the entire repository except for the mysql_real_escape() function.
• Ruby? Dead because of scalability issues. The Ruby community collapses onto itself trying to attent Perls funeral, but somehow get lost and finds itself at YAPC wondering why the Perl community didn't even bother showing up at the funeral.
• Python? Dead because of GIL, and it's either running Jython or IronPython, and nobody wants to sleep with Oracle or Microsoft that badly.
• Java? Death by 3 and 4 letter acronyms and frameworks of frameworks. Research has shown that long term webdevelopment in Java is considered harmful to your sanity.

Kidding aside, look for a set of qualities in whatever language/framework you want to use:

• Does it make it easy to do what you want to do?
• Is there an active developer and user community?
• Is there decent documentation?
• Does it offer a SIGNIFICANT advantage to port your existing stuff to this language/framework over the currently used language/framework? (Time being money, and all that)
• After starting a (small) test-project with it, do you feel confident that it meets your standards for doing real work with it?

I know that it's probably generic bullshit you're getting from me, but you're going to get a thousand answers all screaming at once "Pyramid" "Django" "CakePHP" "CodeIgniter" and what not and unless you take a look at the languages and frameworks and see what people are / have been building with it you'll be none the wiser. Pick something you see yourself maintaining without pulling out all of your hair in the next couple of years.

Re:No good answer

[TheDarkMaster]

Java is useful on the server side, if you keep away from the insanity of "fashion frameworks". Use only libraries (no frameworks), keep it simple stupid (yes, you can do that using Java), and you will accomplish good systems using it.

Like all things, it depends...

[yathaid]

There are a few axis along which you can do the comparison -
1. Developer Productivity - A save and reload framework might be more suitable if that is the existing mindset in your group. This seems to be a very underrated factor while judging your framework/dev set-up.
2. Existing codebase's dependencies - If you have a lot of dependencies which cannot be easily replaced in your new language, that is going to be a problem.
3. Performance of the framework - You want to have at least one large software shop using the framework whom you can use as a guide.
4. Community - This comes down to not just library support for future use cases; the rule of thumb is, if the first few setup issues you are having are easily solved by answers from StackOverflow, you are probably OK.
5. Recruitment - Languages/Frameworks often define the culture of a workplace and directly affect your recruitment base.

Actual Suggestions - 1. Scala/Play - Can use existing Java libraries. Encourages a less verbose coding style than is typical for Java. Twitter moved their Rails circus to Scala. A big con - their language bumps are apparently frequently non backwards compatible. So you might have to hold for a bit until things stabilize.
2. Rails - Easy setup. Solid Community. Good testing framework. Cons - Proven to not scale at Twitter. There are at least two other examples of Rails not scaling. Why jump ship twice eh? Dynamic typing is not exactly helpful when your code reaches a certain LoC count.
3. Golang - Good concurrency model. Easy to read code, almost a C-with-concurrency. Backed by Google; this is not going to be abandoned because a lot of internal Google teams are deeply invested in Go. Cons - Not as popular yet as Scala or Rails, so lesser library support; but rapidly expanding community.

ThoughtWorks has a languages and frameworks radar that can serve as a good 10,000 feet survey of the field - http://www.thoughtworks.com/ra... . In an ideal world, do not get too invested in any one framework.

The problems with perl - (I work in a large perl shop, if not the largest perl shop.)
Recruiting is a pain.
New devs need to get comfortable with perl idioms; a pattern that seems to encourage code obfuscation more than readability.
Optimal runtime concurrency is impossible. Even if you roll our own Futures library.
Bless is not safe. Consequently, you lose any sort of concrete interfaces.
There is no concept of unit testing.

Re:Grails

[Kagato]

I'm going to second Groovy on Rails. AKA Grails. It's very mature and is one of the languages that compiles down to Java Opt code. You have a large eco-system of production apps that run in the container. The language is fairly approachable (saying this as someone who came originally from a Perl Web App background in the late 90s). You can also use Java Libraries if there's something you want to get out of box such as one of the many Open Source Apache Libraries or Google Guava Libraries.

Java or C# + AngularJS

[mlk]

Find yourself a good REST writing API (I'd go Jersey & Guice, but many go Spring for Java) and then HTML AngularJS as your front end framework.

Re:Java or C# + AngularJS

[asylumx]

Agree. Also .NET MVC is really getting pretty good as a framework.

Re:Java or C# + AngularJS

[BaronAaron]

This.

The days of server-side framework being closely coupled to the client side presentation layer are over. Write the frontend in plain HTML / Javascript. Use a Javascript framework to make life easier. Do the server-side as a RESTful service.

Java or C# would be good server-side languages, because of the ease of finding developers.

I personally prefer C# and ASP.NET MVC Web API. A completely open source solution when you use Mono.

Re:Java or C# + AngularJS

[Slashdot Parent]

I agree that server code is moving toward being an API for a client-side presentation layer, but it's hard for me to recommend a specific JS framework at this point if OP wants the thing to stand the test of time. Angular is certainly the flavor of the month, but jquery was the next big thing not too long ago.

I also see some of my clients moving to Jade templates. It's in a bit of a state of flux.

Crystal Balls

[Tablizer]

If someone was able to predict the future that well, they'd be buying out Warren Buffett instead of answering questions on slashdot.

Perl does seem to be on a downward popularity spiral. Whether it merits that or not would turn into a heated debate, so I'm only stating that from the perspective of having enough usage momentum to provide sufficient shop staffing options and support in the future.

PHP would be my rough best guess, if you want a dynamic language in the same general family as Perl. PHP is a bit clunky, but has huge current usage and has not shown any signs of slowing down. IF it started dying tomorrow due to some newfangled language or gizmo, it would take decades to fully kill.

Python and Ruby have failed to fully catch on mainstream, and the "white space" issue still haunts their growth. It just agitates enough developers to keep them down. (I'm not putting a value judgement on the white-space thing here, only looking at perceptions.) Plus, their communities seem to overdue "clever abstraction" coding, at least in terms of what the market prefers. They suffer part of what Lisp does, in terms of market perceptions and reactions to high coding abstraction. The market likes mid-brow languages, not high-brow.

C# is still too tied to Microsoft's fortune, despite having OSS clones. If MS sinks, it may take the clones with it out of industry support/momentum fear (not necessarily language merit).

And Java is currently haunted by Oracle's Big Lawyer ways.

FORTRAN

[josquin9]

. . . at least according to my Dad, who started programming in the late sixties.

"NASA used it to put a man on the moon, dammit. I doubt your projects are more complicated than that, so it should be all you ever need. (Unless you're writing a business application, of course. Then you should use COBOL.)"

Fractal rant makes about six good points

[tepples]

Anyone cosidering PHP should read this the now infamouns "PHP is a fractal of bad design".

Which must be balanced with the "hardly" rebuttal. For example, PHP lets a program solve the exception/warning dichotomy cleanly in about six lines of code; see the manual's page about the ErrorException class. This leaves about a half dozen legitimate complaints:

• No way to turn off the language's loosely-typed comparisons.
• Parse errors and undefined function errors are fatal rather than throwing an exception that the caller can catch.
• Inconsistent naming conventions in the standard library.
• Associativity for the ternary ?: operator is the less useful side.
• PHP allows the server operator to change program semantics in ways that are annoying to work around, such as not allowing a shared hosting subscriber to turn off "magic quotes" or not following HTTP redirects in libcurl.
• PHP versions change the semantics of existing programs in ways that encourage shared hosting providers to continue to offer only outdated versions of PHP, making it impossible for web application developers to take advantage of new features.

Re:Fractal rant makes about six good points

[Bucky24]

Regarding your code example, you can always write it as

if ("".equals(firstName))

because you never have to worry about "" being null (and if firstName is null, the equals returns false). I used to do it the same way as you before someone pointed this out to me.

Re:Fractal rant makes about six good points

[tepples]

How does the presence of "C and Python crash fatally, potentially destroying the memory space of other programs. Got it." invalidate the whole rebuttal? Even if it isn't sarcasm, when programs hit undefined behavior, they can scribble on other programs running in the same process space, such as if your web app is loaded as a module instead of a CGI program. Granted, this is harder to do in Python without using native code interfaces like ctypes.

Re:Fractal rant makes about six good points

[Bite The Pillow]

Predictability is a lot more important than you seem to think it is, and languages behaving inconsistently is a lot more of a problem than you think it is.

The naming convention makes reading code a lot more readable, and a lot easier to understand. Also, depending on whether your IDE supports autocompletion completely, partially, flaky, or not at all, it is a lot harder to make stupid errors if types and functions/methods follow a pattern.

Having functions return false, but some functions throw an exception, is an inconsistent design. If the designers started out with returning false, then changed to exceptions, that means they changed their minds and decided that false was not a good design. And functions still return false because it would be a breaking change. So now it's both poorly designed AND inconsistent.

The 'Concise' point seems to be minimizing the example. With a try/catch you can catch every failure, not just one per line, with a single handler. I'm used to languages where you can catch and log the exception, and language constructs clean up resources. Any code-managed resources can be cleaned up in the catch block. One try, one catch, a call to a log, and most of the time that's it. As opposed to a try/catch around every line of code, which seems to be the slant of this paragraph.

I don't understand the point about 'Debuggable' because I never used it. I also never used it with Oracle, so 'b-b-b-but Oracle' is the least convincing argument ever in this context.

I stopped reading about the time I saw the "Arguments" paragraph, because so far the author is exactly as guilty as the previous author.

In short, we have two people who fundamentally disagree on the precursors to software development arguing their beliefs instead of making a solid, language-agnostic argument. Everything they argue is skewed way out of proportion, and the counterexamples are ridiculously oversimplified.

There is not a true rational argument here, other than both authors pointing out legitimate shortfalls of PHP I concede, not having read nor written any PHP, that it was poorly designed, just based on the rebuttal you linked to alone.

Point me to a rebuttal that is more than essentially "You're right, but it's fine and everyone else should be totally okay with it broken this way" and maybe I'll change my mind.

Re:Fractal rant makes about six good points

[genkernel]

I don't know, I don't think that guy from devshed defended his case well. In some cases he completely misses what the fractal article was trying to say. He says that the settings in php.ini that the fractal design article mentions are not problematic. He even says that the intransitive == operator is merely a result of loose typing and there is no legitimate issue there.

The == operator is listed as "flaky." The == operator is the core of loosely typed languages, and is immensely powerful. He thinks it's flaky because he can't wrap his brain around loose comparisons

And it gets worse:

array_search, strpos, and similar functions return 0 if they find the needle at position zero, but false if they don’t find it at all. In C, functions like strpos return -1 if the item isn’t found. If you don’t check for that case and try to use that as an index, you’ll hit junk memory and your program will blow up. [...] In, say, Python, the equivalent .index methods will raise an exception if the item isn’t found. If you don’t check for that case, your program will blow up. In PHP, these functions return false. If you use FALSE as an index, or do much of anything with it except compare with ===, PHP will silently convert it to 0 for you. Your program will not blow up; it will, instead, do the wrong thing with no warning, unless you remember to include the right boilerplate around every place you use strpos and certain other functions.

So basically, if you don't include the right boilerplate around other languages, they fatally crash and destroy their state, potentially also destroying neighboring programs in memory. However, if you do the same erroneous code in PHP, it continues to work with slightly unexpected results. Tell me again why "keeps working" is a problem? Plus, for what might be the 10th time, he just plain doesn't understand loosely typed languages. Yes, false == zero. That's actually an incredibly powerful feature of the language. The boilerplate he's comparing about isn't exactly onerous either. Look, here it is: "!== false". Oh man, look out. That nearly broke my fingers I typed for so long.

Silently failing is bad. Failing catastrophically is preferable to random program behavior. That's the assumption behind what the original quote is saying (which may be explicitly stated in other parts of that article).

So yeah, I think the main purpose of the "hardly" rebuttal is to reinforce why the fractal of bad design article is correct.

Re:Fractal rant makes about six good points

[Tablizer]

1. Re "comparing...loose types": that's the nature of dynamic languages. What's an example of a (default) dynamic language doing comparing right? Explicit comparing operators seem just about the only way (I've proposed symbols in my pet drafts), other than explicit conversion of the operands, which is redundant.

3. Re: "inconsistent naming": Any sufficiently large library that has grown incrementally is going to have naming and parameter convention oddities. Choices appropriate to a small name-space may not be appropriate to a large one. The only way to get that right is to design the big library up front, which is not something many languages get a shot at. What's an example of an existing language with decently named library parts?

5: Re: "server operator changes": That's a flexibility trade-off. I'm not sure I'd classify that as summarily "bad". Arguments could be made for either.

6: "Versions change semantics": That's another trade-off in improving the language versus backward compatibility. I'm not sure I'd classify that as summarily "bad".

Re:Fractal rant makes about six good points

[tepples]

i'm not sure how you can possibly have read this thread and concluded that only six items from the original lengthy post are valid.

I admit to having grouped similar points from "fractal" together to make the strongest half dozen talking points.

Re:Fractal rant makes about six good points

[tepples]

I haven't tried every dynamically typed language out there, but I have tried Python, and it doesn't share a lot of PHP's faults.

What's an example of a (default) dynamic language doing comparing right?

Python at least doesn't aggressively try to convert strings that look like numbers to numbers to compare them numerically.

What's an example of an existing language with decently named library parts?

Python adopted PEP 8 fairly early on.

"Versions change semantics": That's another trade-off in improving the language versus backward compatibility. I'm not sure I'd classify that as summarily "bad".

Python allows each module to specify its own semantic versioning either with new syntax (such as with or new-style classes) or, when old syntax would get new semantics, with from __future__ statements.

Re:Fractal rant makes about six good points

[jlowery]

Which means it isn't equivalent. The point of this: $gt; if(firstName == null || firstName.equals("")) Is to check to see if the string is null or empty.

Nope.

if(firstName == null || firstName.equals(""))

says "I don't care which", whereas

if(firstName == null) {
}
else if (firstName.equals("")) {
}

actually checks if the string is null or empty

Re:Fractal rant makes about six good points

[Tablizer]

There are trade-off's to different comparing techniques. My preference would be a symbol for explicitness in intent. Example:

$a #> $b; // # for numeric compares (greater than)
$a @> $b; // @ for date compares

If the variables couldn't be interpreted as the indicated type, then an error would be triggered. (Perhaps fancier compare functions could allow more contingency handling for such.)

So future language designers out there, THAT'S the way you do dynamic compares.

As far as Python's versioning techniques, PHP could adopt that practice also for new versions, but probably chose not to for a reason. Per module versioning could get confusing. I'm still hesitant to call that a "flaw" in PHP, but rather a personal preference instead.

"Ossifying" vs. "Stabilizing"

[DutchUncle]

... because people saying that something is "ossifying" and jumping to the next fad is EXACTLY what makes things "buzzy".

Re:PHP with Banshee framework

[Aethedor]

Don't focus on a language only. Also look at a good framework. My advice is the Banshee PHP framework. It mainly focuses on security, which is the only important thing these days. I know this will be seen as spam, but do yourself a favor and just take a look at it for 15 minutes.

Random garbage or valid Python?

[John Bokma]

http://preshing.com/20110926/h...

Perl is the language, perl is what runs Perl

[John Bokma]

This is a tech site, right?

Yesod

[John Bokma]

http://www.yesodweb.com/ Lookie, it's even in the domain name ;)

Re:Yesod

[ChunderDownunder]

Where 'y' is a typographic substitute for the olde English letter thorn, I'd personally steer clear of anything named 'The Sod' :-)

Coming from a JVM background, from the familiarity p.o.v. I'd probably prefer to write web services in Scala but certainly faylang is an interesting diversion from dynamically typed compile-to-JS languages,

We all hate legacy code

[UrsaMajor987]

We all hate legacy code and want to work with something brand new but Perl is actually a very useful language. Don't forget to add performance to your list of desired attributes. Here is a performance comparison between several popular languages http://raid6.com.au/~onlyjob/p... . At least for the tests they were conducting; Perl was very quick.

Re:We all hate legacy code

[stewsters]

That is a really shitty comparison, they cheat and try to make Java look a lot slower than it is.

The Java version they used was 5 years old, asked the system what the total memory and free memory used was during the loop multiple times per iteration (none of the other ones ask in the loop even once), and uses immutable Strings rather than a StringBuilder.

Legacy definition

[aandolan]

We should strive for a decent definition of legacy.

What's not a fad is now legacy. I work on Ruby-on-Rails r3 and the programmers already consider it legacy, since r4 has been out a while. Legacy should mean something similar to all: maybe not easily runnable on today's hardware (needs special emulators, ...), not having security updates, ... e.g. Cobol or ...

Spring Boot

[stewsters]

Java, using Spring Boot with an AngularJS frontend.

Hiring

[oneiros27]

Most of the people who know Perl well already have jobs, and aren't looking to change.

We tried hiring someone to help me offload some of my work, and one the task I've gotten behind on is updating & maintaining some Perl code.

We had one person who I felt could've jumped in, but that management didn't like (as he had previously worked here, and left). The rest were folks who we'd have to train on OO, closures, and other higher level concepts.

If this hasn't been offered as a 12-month position, maybe we could've found someone. If we had advertised it as a general programming job, and then taught someone Perl, maybe it would've been gone better for us.

With trendy languages, you at least get people willing to apply -- even if it's the case that they don't grok the language, you at least get someone you can train up.

Re:Hiring

[oneiros27]

Government contracting -- we got a bump in our funding for the year, but due to sequestration we knew we wouldn't have it permanently ... so we were actually honest in the job advertisement, rather than sucker someone in and cut them at the end of the fiscal year.

I got some interest from people who were willing to work remotely, but the manager (contractor) that was heading up the hiring wanted it to be a W2 position and not a 1099, which I assume is why I never got any of those resumes to review.

Re:Hiring

[david_thornley]

I'd say it's more important for them to know higher-level concepts than to know Perl. Somebody who can hack through bad Ruby is going to be less useful than somebody who knows C++ (including the regular expression library) and is comfortable with the concepts. Learning Perl is a lot faster than learning O-O, and some people just aren't going to get closures. If you're looking for actual competent people, you're probably better off not looking for people in the hot language du jour, because that's where the incompetents are likely to congregate.

You also seem to be thinking of rewriting your software to get better results in a twelve-month gig, which seems to me to be backwards.

Re:Hiring

[Slashdot Parent]

Most of the people who know Perl well already have jobs, and aren't looking to change.

Honestly, I think that most people who know Perl also know not to sign up to slog through some unknown Perl codebase. I've seen Perl code that is well-written and easy to understand, and then there's the other 90% of Perl code that looks like Q-bert cursing up a blue streak.

I've long-since removed Perl from my resume.

PHP

[Mr. Slippery]

PHP is the language for web programming, just as C/C++ is the language for system programming.

People have been hating on C since at least the 1980s. It's still here. People have been hating on PHP since 2000 or so. It's still here.

Not to out myself as a fanboy....

[Captain Arr Morgan]

but NodeJS is making strides these days. And despite a lot of talk otherwise, JS isn't going anywhere. The code reusability factor is really nice, the module ecosystem is growing by leaps and bounds. The framework side of things is where I think Node is currently still lacking. There are some options available, but in my experience so far the 'complete package' (RoR, Django) isn't arrived yet.

Regarding the linked article on Perl...

[jjn1056]

I'm not going to take sides on 'what language to learn next.' You've not given us enough information on your codebase, the size and nature of your company, etc. I would say a rewrite is as likely to put you out of business than not, but that's ultimately your choice and unless I know all the factors I can't tell you if its a risk worth doing.

Regarding the link you gave on Perl 'ossifying', there was actually a signification discussion on the Perl Reddit about that article which I want to point out:

http://www.reddit.com/r/perl/c...

I would say the website that generated that article seems to be some sort of SEO play (they just have a bunch of articles on stuff that has some interest and controversy) and they stick ads on it. There's nothing mentioned in it that hasn't been mentioned 100K elsewhere (including here on Slashdot).

Perl has pluses and minuses but I've made a good career at it, and most of the code I've worked with is newer (seldom more for 5 or 6 years old), not legacy stuff from before the first dot com bubble. I'll probably make 200K this year, so I can't say its a bad choice. I work with lots of fun people as well. I also like Javascript. If I was starting today I might choose Scala, its a nice clean, fast language with a lot of forward looking concepts. Best of luck whatever you do.

I know why you are asking, you said "Legacy"

[turp182]

The key word in the summary is "legacy". This indicates that there is a large code base that the current developers are not too familiar with (deep knowledge, staff turnover causes this). This causes an organization to fear change due to the related complexity of changes and potential regression bugs. I'm going to guess that there aren't large, mature suites of unit and regression tests.

So I believe you have:
1. Complex code base without a lot of deep developer knowledge of the innards.
2. Fear to change things too much due to complexity and the possibility of introducing bugs.
3. Do not have effective, wide coverage testing implemented.

But, you also have good knowledge of Perl and the architectural elements that compose the system (server software, external libraries, etc.). That knowledge is very valuable and shouldn't be dismissed just for the sake of changing the base language of a system. And you have a working system. How many person years of development have been put into it? Are you willing to spend that much time on the replacement (do you think a replacement could be built in less time, and if so, why?)?

As well, rewriting large admin systems is very risky. I've personally seen two such efforts fail, a 100% failure rate from my personal experience (both had budgets over $5 million, one was over $40 million). Here's an article on this topic:
http://hbr.org/2011/09/why-you...

Consider keeping the existing system, but embarking on a long term (years) modernization/re-design/improvement effort to make the system more modern (ie. easier to work with). Focus on small, non-breaking changes that can go out with regular enhancement promotions (the modernization effort should be able to stop at any point, with any improvements to the system staying in place - this allows for tight budget control and financial risk mitigation). Hire a good application DBA to perform analysis and recommend changes to the data model. Hire a good software architect or bring in architectural consultants that can bring a different perspective to the understanding of the application, its goals, and how it could be improved.

Here's an article on approaching IT projects in a "Small and Simple" manner:
http://w.objectwatch.com/white...

Re:I know why you are asking, you said "Legacy"

[turp182]

Another approach rather than in-place same-tech modernization is the Strangler Pattern, coined by Martin Fowler.

This involves building a new application (or applications, utilities can be important) "around the edges" of the existing one, rewriting functionality aspects into a new system; chipping away at the old system (give the users a better solution for some things and they will not mind working with two systems).

Here's Mr. Fowler's original article about such:
http://martinfowler.com/bliki/...

Any sufficiently complex solution approaches Perl!

[Anonymous Coward]

Given any "clean" language, if you introduce enough complexity, like regular expression parsing, HTML emitting, inline anonymous functions/members, and so on, it's going to look like Perl. At least Perl has tools to mitigate itself through its module system to hide the crud. Top-level Perl programs look clean and maintainable if you push all the crud down into modules and subroutines. The same people who complain about Perl being ugly are the ones who write page after page of anonymous class implementations in Java.

Tools Command Language (TCL)

[mi]

TCL is both awesome and mature. It is also evolving, but the maintainers are very careful to maintain backwards-compatibility (unlike the Ruby-crowd). Two different Apache-modules exist.

Unlike with PHP, you can also write long-living TCL-programs — though PHP core is Ok, various extensions leak memory because nobody really uses the language for anything other than short-lived web-pages. Adding a GUI to your non-web program is also easy (with Tk), as is handling the cases, where GUI is not available — you can degrade gracefully to a non-GUI mode, rather than see the program refuse to even start.

The only real competitor to Tcl is Python, which is what Google are using, but extending Tcl with your C/C++ code is much easier, than extending Python (or any other candidate — Tcl's API is the best thought-out and stable).

Re:Tools Command Language (TCL)

[GeekBird]

Ugh. I still have TCL nightmares. Space delimited crap;, clunky as hell. Ugh.

Re:Tools Command Language (TCL)

[mi]

Space delimited

You must be talking about Python...

VPS costs several times more

[tepples]

Why are you letting your hosting provider choose your language? Just get a VPS.

True, a VPS is a better once you get to a certain scale, but it can be more expensive for those just starting out. Shared web hosting from Go Daddy, for instance, starts at $3.49 per month, while a CentOS VPS from the same company starts at $19.99 per month. And a VPS is only going to get more expensive over time as IPv4 addresses run out.

Counterexamples would be appreciated.

Re:VPS costs several times more

[aerivus]

The landscape has changed. VPS used to have a large additional cost compared to shared hosting. This effectively limited smaller budgets to the web programming languages the shared hosting provider supported - mostly PHP. VPS is now as cheap as shared hosting:
Digital Ocean VPS starts at $5/month
Linode VPS starts at $10/month
There are even sites dedicated to just cataloging inexpensive VPS hosting
Personally, I just started using Digital Ocean on the $5 month plan; just the low latency of their VPS makes it a big step up from my prior shared hosting provider (Bluehost), despite the same cost.

Re:VPS costs several times more

[Nexion]

But now you have to maintain it.

money++

No, I mean competently.

money++++++++

Once upon a time I maintained servers. PHP updates due to the combination of "upgrades" and exploits make me VERY happy to no longer be administrating machines. Seriously... it was like it PHP was attempting to be the third banjo in the dueling banjos of fail known as Java and Flash. Bringing something like the bane Java and Flash are into a server context, as opposed to client, is something I would rather avoid. Sure, "It's totally mature now!", just like it was when I was a server admin.

Re:VPS costs several times more

[Mdk754]

Digital Ocean sells VPSes starting at $5/mo...

That's not a huge step up from $3.50 and is infinitely more useful.

Re:VPS costs several times more

[Slashdot Parent]

PHP updates due to the combination of "upgrades" and exploits make me VERY happy to no longer be administrating machines.

I've never tried to maintain PHP before, but really, if you used Debian Stable or an Ubuntu LTS, you had trouble with PHP security patches? That surprises me.

Sounds like you need a better test suite.

It's simple

[Orestesx]

Perl was used by programmers who wanted to spit out web pages or create back-end scripts to do things like send emails or file forms to a database. Non-programmers weren't invited.

Then PHP came along and could be used by web content creators who wanted parts of their page to be dynamic. This is just a better, easier to understand paradigm that allows people to collaborate much more easily.

Research

[tyggna]

Every web framework and technology has benefits and drawbacks. It's a matter of finding the right fit for your company. It's a good thing they're letting you ask the question, because managers/bean-counters make bad decisions in this area claiming that devs can't "see the big picture." Find one that fits well with your system and needs.

But, I assume that's why you're asking slashdot--you don't know what's out there or what their benefits are.

Well, I've spent the past 7 years benchmarking web frameworks and systems and I'll share a bit of what I've found out. Keep in mind, all information given here is my opinion and subject to debate and correction.

First--if you need near-infinite scalability and the absolute best performance, there is nothing that can beat mongodb for a database backend with fastcgi++ for your "framework." Mongodb is a bit buzzy still, but there are good reasons for that. It scales extremely well, and was designed to scale at speed. Fastcgi is anything but buzzy, but it's the fastest there is and it's built right into most webservers--but you're writing C/C++ code so that's an odd beast to deal with.

Now that I've said something that management will undoubtedly shoot down, here are some other frameworks and what they were originally designed to do, and some highlighted features.

Python - Django : "perfectionists with deadlines." Django was designed to chug out simple, straightforward web applications as quickly and cleanly as possible inside of your overall project. Contains template inheritance that has a small learning curve and is very powerful. Uses any SQL backend you want and provides an abstraction layer for it with caching. Cons: can be pretty heavy for a webapp, and difficult to integrate into a production environment.

Python - Flask : Simple and lightweight. Uses the same templates as django, but no database backend. It's meant to be standalone and simple (5 lines of code will get a website up). It's easy for your code to grow unwieldy inside of flask.

Ruby - Rails : Continuous development and test-first environment. This is kinda the poster boy for buzzwords, in my opinion, but it has some strength beneath it. Ruby is largely on-par with perl, so you have that. Rails provides the data modeling and really streamlines a lot of the annoyances common to web development. They designed the system to be the whole "45 minutes to a production environment" pipeline. You're supposed to write your tests first, then your code, and you write your deploy scripts and settings before you even start your project.

PHP - Drupal : Make a website without knowing crap about making a website. Haven't used it personally, someone else can comment.

PHP5 : "Hey, let's fix all the problems with PHP4!" Seriously, though. PHP was meant to add one-off server side scripts inside of your html, and has grown to be so big in comparison. PHP5 is actually a good language though, but it took a while to get it there. It's best used for image data processing, in my humble opinion, but it's on-par with any other language out there.
So, search them, find out who is using which systems, and which ones seem the most similar to your setup and go from there.

How to Fail

[Safety Cap]

1. 1. Rewrite your code
2. 2. Fix all the bugs you introduced that didn't exist in the original
3. 3. (and ongoing) Run into all the edge cases that were discovered and solved years ago in the original code.
4. 4. Spend tons of manhours and tie up your talent pool rewriting just to get where you are now instead of adding new features.
5. 5. Embrace your FAIL

Re:How to Fail

[FlyingGuy]

1. Rewrite your code [joelonsoftware.com]

I mostly agree with what this guy says with the exception of Quatro by the old Borland. Quattro by all accounts was eating Lotus Development and Microsoft's lunch in the spreadsheet department. It had WYSIWYG natively before either of them ( 123's was an add-on and excell didn't even have one) and it worked beautifully. Embedded graphs were there, Multiple Sheets and a function library that was richer than either of the others.

Then the Look & Feel lawsuit hit. Jim Mansey ( if he stood in front of me today, I would punch him hard and punch him again even harder ) after having let 123 rest on it's laurels took Borland to court, in Boston. Borland eventual prevailed but not until it had spent most all it's cash and suffered the basic abandonment of Quattro by the marketplace because of the suit.

That really was the beginning of the end for innovation in the spreadsheet world. Excel has turned into a bloated beast that no one really likes, but it is the only thing left in the marketplace ( Don't get me wrong I wholly support Open / Libre Office but they will never overtake Excel as the simply have to play catchup constantly ) that anyone can field. Quattro still exists but the last release was about 2 years ago

Re:How to Fail

[Half-pint HAL]

Innovation in spreadsheets? The only innovation spreadsheets need is a bullet in the head. Spreadsheets are the worst of bad programming practices opened up to the wider public. Kill them. Kill them with fire.

Re:How to Fail

[FlyingGuy]

ROFLMAO!

Spreadsheets are great tools for accounts and they have made their life a lot easier. But you are right, they are evil because suddenly accountants started using them to do things that should have been done in databases etc. But I think we have only ourselves to blame if you really think about it.

Re:How to Fail

[Half-pint HAL]

Calling a spreadsheet a useful tool is like calling a blank piece of paper a useful tool. It is true. However, an enterprise that ran entirely on blank sheets of paper that individual employees used in whatever way they felt inclined would be a complete disaster, because the company's information would be inconsistent and unstructured. And yet we allow people to use spreadsheets, leaving their data inconsistent and unstructured.

The limit of tasks that should be done on spreadsheets is ad hoc calculations up to A6 size. Anything with any sort of tables and references should be done in a not-quite-a-database-but-not-really-a-spreadsheet type app.

Not an answer ...

[MikeBabcock]

Sadly, I really enjoy writing code for Zope. ZPT is a great way to integrate functionality to legit HTML, writing Python modules for Zope is incredibly powerful and even without them, the Python scripts and SQL functions built-in are very nice and easy to use.

I said sadly because its not nearly as well supported as that bastard child of the web, PHP. Zope gives Python an API wrapper that makes it easier to write large applications in than pure Twisted for instance, or PERL CGI on Apache even IMHO but its hard to find others who are accustomed to it so it can't be recommended here.

REST + pure HTML5/JS frontend

[Laz10]

Generating HTML on the server is more or less outdated.
So a "web language" on the server doesn't make sense, the way it used to do (like perl cgi, ASP, JSP, PHP and decendents)

What you do now is write the frontend in one of the new JS/HTML frameworks that run exclusivly on the client.
AngularJS is popular and will likely stick around in one form or another. But pick any you like.

For the backend you want to expose REST services, that serves the content in a way that is easy to digest for the frontend (so you don't end up with too much logic out there).
For that I'd recommend taking a look at Scala (10 years old, and not going away) and the Play Framework (http://www.playframework.com/)
What is nice about the Play framework is that it not only makes it easy to expose REST services. It also makes it easier to deploy the client side framework.

Also take a look at using microservices. Using that architecture enables you to write the REST services in smaller components, rather than one big server. That way you can more easily replace each service, when you want to migrate to the next backend technology.

Re:REST + pure HTML5/JS frontend

[Actually, I do RTFA]

I'm confused. Your suggestion to "what web language should I use" is to tell him to choose any JS framework (without helping him) because it's uncool for the server to actually do server work? Expecting my computer to do the work you should be doing... well, that's a non-starter.

Bottom line, I don't trust JS blindly, and don't understand why other people do. But then again, I never get why people let google-analytics track them, or ads display either.

Re:REST + pure HTML5/JS frontend

[dave420]

Google Analytics lets the websites you use know which parts are working, which are not, which are visited and which are rarely used. It lets them know what browsers their users are using, letting them tailor their site to their users needs. It essentially lets the websites people use do what they're trying to do more effectively and efficiently. Ads pay for the websites. If no-one used Google Analytics or viewed ads, they would have fewer sites to use, and the sites they could use wouldn't be improved based on their users' habits. They would have confusing navigation, and the users' flow between pages of interest would be convoluted, making the sites harder to use.

If you want to go back to the internet of the late 90s, fine - but to be ignorant of the benefits is just being lazy.

Re:REST + pure HTML5/JS frontend

[Actually, I do RTFA]

Google Analytics lets the websites you use...

And Google do the same. Don't get me wrong, we use Google Analytics on our site as well. But I still don't get the benefit to me.

Ads pay for the websites

That may be true. But if so, companies need to start running QA on the ads they serve. I don't like animation, sounds or drive-by installers.

. If no-one used Google Analytics or viewed ads, they would have fewer sites to use, and the sites they could use wouldn't be improved based on their users' habits. They would have confusing navigation, and the users' flow between pages of interest would be convoluted, making the sites harder to use.

I would contend they would have better navigation - at least for me. So many people who think like me turned off any extraneous connection to Google - including Analytics - years ago, so that the people now "voting" are not representative of me or my use habits. Hence, among other things, the new /. Beta.

Nor would my singular action produce enough of an effect to warrant the cost to me of Google developing a more complete profile.

If you want to go back to the internet of the late 90s, fine - but to be ignorant of the benefits is just being lazy.

Still, haven't heard any benefits for me to participate.

But yeah, speed aside, I'm not sure why people hate on the early 00's internet. It had great things like a separation of form and function.

But the things you're thinking about definately came later.

JavaScript Sucks, Rant [Re:Node.js]

[Tablizer]

Most developers only use JavaScript because it's their only realistic option on the client side for web-based applications. It's kind of like the QWERTY standard: you have to use it because avoiding it is made difficult by entrenchment.

I don't know if better tools (IDE's, interpreters, lint-er's, etc.) could make it more tolerable, but most of us have had a crappy experience with JavaScript in browsers, and this has damaged its reputation such that unless something comes along that repairs its reputation on a wide scale, server-side JavaScript is a tough sell. You can't just make it good, you have to show the world it's good and that their shitty browser experience was the browser's fault and not JavaScript.

The browser only seems to give one of two unhelpful errors: "object not found" or "is not an object'.

As far as the language, I don't like its non-WYSIWYG typing model. It has too many nulls, nils, NaN's, Nuns, or whatnot that drive one crazy. I prefer a typing model where every value is or is treated like a string and is readily displayable. No damned hidden types/modes. (Some say Null is needed for RDBMS compatibility, but I've almost never needed such, and the API can use the string "[null]" or the like if null detection is really needed by an app.)

And it has too many "kinds" of data structures; these may be delimited or enclosed with square brackets, curly braces, parenthesis, and whatnot. Too many similar kinds of collections. Just make everything a dynamic ordered tree rather than have similar but not quite the same species of structures. Lisp at least got that part right.

And don't overload "+" to mean both addition and concatenation. Slap the bastard who put that "cute" feature in.

Oh, and literals starting with "0" are interpreted as octal. Cute Marie, real cute. That feature almost got me fired from a contract once because the customer didn't believe such a design flaw could exist in a common language, thinking it was my fault. There's probably only 7 JavaScript programmers who use lots of octal literals; why the hell did you ignore the other 99.999%? Were you targeting cephalopod coders?

And JS lacks typical string- and date-handling functions. Lots of octal-friendly shit and no fucking strings; must be cephalopods.

Re:JavaScript Sucks, Rant [Re:Node.js]

[narcc]

Oh, and literals starting with "0" are interpreted as octal.

It's funny. I was actually quite grateful for this feature -- it came in quite handy on a personal project years ago.

I wouldn't be so quick to count it as a design flaw as lots of languages work that way. C/C++/Java/Python2/Ruby ... it's quite common.

Re:JavaScript Sucks, Rant [Re:Node.js]

[Tablizer]

(A=top list, B=bottom list)

1A: But they don't work for JS as it runs in other browsers. We can't control what browser a user is using. True, that's more of an implementation issue than a language issue. But such still damages JS's reputation, risking legacy status earlier, which the author was concerned with.

2A: "Just remember goofy rules" is not a good enough justification in my opinion. JS doesn't need those things: chop the fuckers out. (Paraphrased)

3A and 6B: What's wrong with using an ordered tree for everything? It can even represent tables (although not practical for large tables, but that's not the job of an app language). I don't need heavy-ass app speed for most of what I do: dump the volume processing onto the database if you have to chomp on large collections. Note I agree that many other languages do collections worse than JS. I guess we can agree that JS is at least average there.

6A: Trim is one of the most common string functions I need.

Oh, and JS lacks optional named parameters, something I really miss. Once you get used to them, they are hard to give up.

1B: Objects, with method defining or overriding, is good enough for the same thing, better understood among programmer population, and often more flexible in my opinion. Heavy use of HOF's usually indicates bad coding or bad API design in my opinion.

4B: Explicit number types are not very common in dynamic languages anyhow. That's more of an issue of comparing dynamic langs to static ones.

7B: Certain bad coding idioms seem to be fads for a while, and then people realize they over-did it and go back to judicious use.

Thanks for your feedback. Even though I may not agree on everything, I enjoy counter views.

Re:JavaScript Sucks, Rant [Re:Node.js]

[polymeris]

>Most developers only use JavaScript because it's their only realistic option on the client side for web-based applications

Every day that passes that becomes less true, though. Apparently, C compiled to asm.js (or one of the alternatives -- I forget) is already faster than handcoded JS. Just a matter of time before a nicer ecosystem becomes available.

I, for one, am happy about that. While I don't dislike JS as much as you, having choices is good.

Re:JavaScript Sucks, Rant [Re:Node.js]

[TheDarkMaster]

This. Javascript is the dumbest language I've ever had the displeasure of working. But I have to use it for not having another alternative when the code needs to be on the side of the browser. Javascript is shit, but we do not have choice.

Re:JavaScript Sucks, Rant [Re:Node.js]

[david_thornley]

And I consider it a design flaw in C and C++, since it's rarely actual useful and is a source of hard-to-track-down confusion. Hex is far more convenient for systems with 8-bit bytes, which nowadays is almost everything, so almost nobody uses octal literals enough to remember they exist. If the literals were something like "0o" like "0x" for hex, it'd be fine.

Re:JavaScript Sucks, Rant [Re:Node.js]

[narcc]

Well, okay. It's never caused me any problems and it's been useful to me.

Your experience is different. You've never found it useful and it's caused you problems.

I'll bet we could make a whole list of common language features that match that. Should we call those design flaws as well?

Wrong reason ...

[kbahey]

I am no fan of Perl, but if you have an application that is mission critical, has lots of legacy code, and just works, then you do not go about rewriting it just because there is some dislike for the language.

If it was something related, such as difficulty of finding suitable candidates for developer positions, then I would understand. But just because "perl is ossifying" does not cut it as a valid reason.

Re:obvious

[awshidahak]

They mentioned node.js, so I believe they mean server-side javascript. That can do proper input-validation.

What's wrong with node.js again?

[Baldrson]

Speaking as a die-hard Perl programmer, isn't node.js the obvious answer for those who want "a web language"?

best language for the job?

[k6mfw]

If you do it for fun, then use whatever you want. If doing it for a job, then it has either been chosen for you by the Project or you select the appropriate language for the task. Of course can have problems if a certain language is better suited but you don't know it and then selected a dud. Probably avoid something that will go out of date soon and nobody will know what it is. For me, ugh I need to learn some of this (been doing html on Notepad since 20th century). My gripe are webpages with tons and tons of script that really don't do much except provide gates for marketeers to blast me with ads and pop-ups. I mean a site that is 2MB of stuff which a 60K html and a few 100K jpgs will do just as good (and download faster). I hate seeing "waiting for aodnqefhgthwe-rhew.googleanalytics.andotherstupidstufftodownload.xml" at bottom of window.

Take Python, for example

[tepples]

After writing tons of Java code that [checks a string variable for both null and equality to the empty string]

Not all implicit conversions introduce problems. Casting to a Boolean type, as the if statement does, is fine with the caveat that which values are considered "truthy" or "falsey" depends on the language. For example, PHP's ordinary bool cast rules are pretty much the same as Python's, except that the string "0" is falsey in PHP but truthy in Python. C and Java have their own definition: a nonzero primitive or a nonnull pointer is truthy. I find these implicit conversions, as well as some language-specific rule for implicit conversion to the language's string type, to make sense in general.

The practical problem with how PHP handles comparisons comes when it performs implicit conversions that make little sense. Strings more often than not end up converted to numbers before they're compared.

For the parse errors, you mean you don't do precommit hooks to do php -l to validate your checkins and don't have continuous integration setup?

You are correct that a lot of people do not. For one thing, they may lack the money to lease both a testing environment and a production environment from the hosting provider. Or they may lack access to server logs because the hosting provider doesn't provide server logs to customers on plans below the VPS tier.

For the undefined functions, if you're doing OOP, the language has had great support for autoloading classes for over a decade

Autoload failures caused fatal errors until 5.3, and some hosting providers were still on 5.2 after 5.4 came out.

The only valid complaint is that the major version isn't incremented often enough to clue people in that there are potential breaking problems.

True. But there are several cases in Python where the interpreter implements both sets of semantics and allows each source code file to select one or the other. Some, such as the division semantics, use the from __future__ statement; others, such as the parallel "classic classes" and "new classes" in the 2.x series, use other syntactic triggers. And unlike Python, where the initial #!/usr/bin/env line selects the interpreter version, the choice of PHP version depends on a server configuration that's often out of the hosting subscriber's control.

PHP is basically a thin wrapper for C libraries.

Thin wrappers are better when they're namespaced. Namespaces allow providing both traditional names and PEP 8-compliant names without overly polluting the global namespace.

Framework matters more than language

[mtthwbrnd]

These days it is more important to have a solid framework and set of libraries than to worry too much about the details of the underlying language that the framework is coded in.

e.g. PHP is not a great language IMO, it is good, but not the best, but Yii PHP Framework is awesome.

Re: obvious

[narcc]

I don't get it either. It seems to have an awful lot of trouble maintaining compatibility between minor versions.

Re:obvious

[Pseudonym]

Javascript. [...] concurrency

Hahaha! Oh, man! Hahahahaha! That is hilarious.

Javascript's idea of "concurrency" is a less convenient version of single-threaded code.

Lua is a good choice

[andrew.starks9137]

Lua is a good choice for what you're looking for: It's not too buzzy, in that it's about as old as Linux. It makes an excellent framework language for many reasons. First, it's a simple C 89 library with a REPL thrown in for good measure. The C API is extremely clean and writing bindings for it is breathtakingly efficient. So, wiring in legacy code is always possible. Also, it is a multi-paradigm. You can make objects, program functionally, stick to good ole' procedural or mix and match. It has a long pedigree, but it has evolved nicely and is now an extremely stable language. It's modern in that it has first class function, block scoping, coroutines with a pretty robust set of functions to support them, a decent-but won't-set-your-pants-on-fire pattern matching system (LPeg is a module you can use for this and it's FAR better than regex, for my purposes). Parts will remind you of JavaScript, but most similarities end at the syntax. Lua is best thought of as sort of... C and Scheme have a baby... Or Scheme that doesn't hate you... Someone on Stackexchange (cannot find the link) said it nicely: Use something like Ruby or Perl if you want to solve a problem and you don't care to know all of the details of how it got solved. You're happy just to load up some modules and get it done. Use Lua if you're the kind of person who likes to really understand what is going on and like to hold the *entire* language in your head. We're using it to build a media framework and the experience has been awesome. Wikimedia recently picked it up and it's been in use in games for a while.

So something no one uses

[thetoadwarrior]

If a language isn'tlong lived or trendy / buzzy then there is a fair chance it's dead. I understand perl is boring now but I'd say stick with that or learn python and maybe brush up on JS without going full retard and doing everything in JS.

My sense

[Effugas]

My sense is that the MEAN Stack (Mongo, Express, AngularJS, Node) is sort of winning. There's some packaging of it over at mean.io.

Personally, I'm really getting interested in Meteor (www.meteor.com). Watch the videos, and realize I saw a smart non-coder go from zero to *ridiculously* interactive site design in three months.

C#

[Alarash]

Use C# and .NET. It's an ISO language, the framework is fully compatible with Linux thanks to the amazing work done by the Mono team, it's a powerful language, Microsoft open sourced a ton of the .NET components this year, MonoDevelop (or Xamarin Studio if you need support) is a good IDE, or alternatively Visual Studio Express (which is free) is even better. Haters gonna hate and all that, but objectively this ecosystem is one of the best for web development.

Isn't it obvious?

[dbIII]

With regexes typically more comments than code just like anything tricky to understand instantly in any language. With the rest just as needed for understanding.
Consider the Carmack transform in C. Can you work out what it's there to approximate instantly based on that line of code without being told? It's things like that and very complex regexes that need the implications listed while the hundreds of lines around them probably don't.

No Problem = No Change

[fygment]

1) Your problem statement is absent. The only thing you have is a worry that the current language is 'ossifying'. That means 'not changing' as opposed to 'not working'. Conclusion: no problem.

2) You don't want 'buzzy' implying that you want something stable, long-lasting .... 'ossified'? Conclusion: You've got that already.

Therefore: you've got what you need. Quit whining and work with it.

Note: you clearly don't have what you think you want ... but if you're asking the question here in \., you really don't know what you want. Therefore: you've got what you need. Quit whining and work with it.

A Promise: when your current software stops meeting your needs, you will able to identify the problems, and then what you need will become apparent.

So many modern options...

[StylusEater]

Dancer? Mojo? or even trusty Catalyst won't do the job? Hard to believe.

Client Side Java? Dead for a decade.

[Slashdot Parent]

I have not seen an applet at any of my clients in over a decade. Server side java, however, is very common.

Python

[yenic]

If you want something used as a web language + more, I think the obvious go-to is Python. I'd personally pick that over PHP, Ruby, Perl etc, IMO it just has longer legs than anything else.

Re:Grails

[Slashdot Parent]

I'd use jruby over grails. You get to code in ruby but run on the JVM. Best of both worlds.

Easier to find ruby developers than grails developers.

Generator expressions

[tepples]

The naming convention makes reading code a lot more readable

Agreed.

With a try/catch you can catch every failure, not just one per line, with a single handler.

And with returning false, you can handle failures even within a generator expression. In Python, statements can do things that expressions cannot, and one of these things is try. This means if you include a function call that may raise an exception in a generator expression, you need to make and name a separate function that tries the call and translates the exception to a sentinel value indicating that a particular call in the list failed. If you're using the warning-to-ErrorException snippet from PHP's manual, then @expression behaves as if there were an inline try/catch: exceptions when you want them, nulls when you don't.

Point me to a rebuttal that is more than essentially "You're right, but it's fine and everyone else should be totally okay with it broken this way" and maybe I'll change my mind.

I wasn't trying to change anyone's mind about PHP being broken. I was only trying to point out that not everybody agrees that PHP is as broken as "fractal" rant author believes it is.

Try LiveCode

[kailasnatha]

Try LiveCode... it is the current 'label" for an xTalk that has been around since 1983. It will be around for another 50 years at least... If Apple had not made some stupid decisions, it would be the language of the web today. Easy to code in, productivie, you can deploy to iOS, Linux, Windows, Android both desktop and mobile, use it on the web server. If the recent kickstart campaign succeeds you will able to design in LiveCode and export to HTML5.

Deprecated = good FOR ME TO POOP ON

[tepples]

I like to say "defecated" and see if anyone notices.

Moving on from Perl

[FlipperPA]

Some of the threads started here have said, "What's wrong with Perl?" There is nothing inherently wrong with Perl, it is still a fine language, if a bit awkward. Compared to other languages, it does feel quite ugly. I've always had a soft spot for Perl, as it was the language I used to make my first web site. I've been moving some legacy code away from Perl, and standardizing more of the organization than just my department into Python / Django. Python has a lot going for it in a lot of settings, and since we're in academia, it makes sense.

We're in Philadelphia, and something I've lamented is there's never been an active local Perl group. Just about every other highly-used language does (as in, the top 10 of the Tiobe Programming Index). PhillyPUG (Python), Philly.rb (Ruby), PyStar Philly (a women's Python learning group), PhillyDB... the list goes on and on.

Python is also the most consistently readable language I've used, and that goes beyond the forced indentation.

YMMV of course, but the major thing for me was having supportive, local communities supporting the language.

my vote

[xuvetyn]

Perl. hands down.

Not caring whether null or empty

[tepples]

I read "check to see if the string is null or empty" as meaning "I don't care which". In practice, I've seen more uses for "I don't care which" than for distinguishing null from empty. In fact, a lot of cases call for not only treating null like the empty string but also disregarding leading and trailing spaces, and that's why I often end up using trim($some_string) in PHP or (some_string or '').strip() in Python.

Re:Grails

[StikyPad]

I would not recommend Grails at all. First, if for no other reason, it's a bit player, so good luck finding developers, tools, help, and all of the other benefits you get with using a language/framework with a large, thriving community. That alone should be enough to steer you away from using it for enterprise anything.

Aside from that, boolean truths are quirky, to put it kindly.

Null evaluates to false, which is ridiculous and doesn't eliminate the need to check for null, just hides the problem if you forget to do it. This is because groovy uses "null objects." Null objects mean yay! no null pointer exceptions, but the consequence is... no null pointer exceptions! So have fun tracking down bugs when things fail silently.

Variables defined in closures (which is most of them) are opaque, so you can't easily inspect them without printing them out or logging them. So now you have no NPEs and no easy way to check for null values versus empty values while debugging without adding debugging code into production code. Ugh! Don't forget to annotate the debug code so you can remove it when you're done.

You don't get compile-time errors for things like using undefined classes/methods (typos!) or sending the wrong argument types. Instead, you have to compile, run, and look at massive stack traces throwing up all over your console/log: http://pastie.org/583115 Then rinse and repeat until it actually runs. And that's before you even start testing actual functionality.

Method entry and class loading breakpoints aren't supported. (This is simply an inconvenience most of the time, but it's worth noting IMO.)

Conversely, since groovy uses convention over configuration, IDEs may flag things as errors which are not. IntelliJ IDEA probably does the best at handling Groovy/Grails, but it still has some issues. My experience was that Intellisense/autocomplete didn't work reliably for Groovy in any IDE, so if that's important to you, you may miss that.

It's not clear where business logic should go. http://bartling.blogspot.com/2...

It's buggy. https://jira.grails.org/browse...

To be fair, I'm heavily biased against dependency injection, dynamic typing, and coding by convention, which are the very concepts Grails is built around. I could go into all of the reasons, but any flamewar worth its salt will list them all for you.

Construct objects and compare them

[tepples]

Another way to do it, supported by both existing static languages such as C++ and existing dynamic languages such as Python, involves constructing objects using factory functions and then using the language's facility for making objects comparable. Comparison expressions might look like intval($a) > intval($b) or strtotime($a) > strtotime($b).

Re:Construct objects and compare them

[Tablizer]

That's redundant because one has to apply the same function/method to both sides. I still prefer the symbols.

Re:Construct objects and compare them

[tepples]

Good luck finding enough keys on the keyboard to make comparison operators for all types in your language's standard library.

Re:Construct objects and compare them

[Tablizer]

Scripting languages typically only need 3 compare types: string, number, and date. Special functions/methods can be created or defined for the custom or rare ones. Use of symbols doesn't prevent other techniques from being allowed. I just want to at least simplify the most common compare types.

Re: (ick) Perl still works, and PHP is fine

[akubot]

PHP is not among my favorite languages, but it is clearly a viable choice for technical and practical reasons. It isn't exactly like the old days ("No one ever gets fired for choosing IBM") but it isn't far away either.

Also, PHP has the CLI, which is a reasonable choice for scripting in Linux shells. So hiring or training someone to use PHP for web development gets you the bonus that they can write other useful scripts too. This lets you avoid possibly less pleasant options such as Perl or BASH. Although I prefer Python or Scala for scripts if not using BASH, PHP is worth looking at for this.