Lisp and Ruby
sdelmont writes "The developers of Rubinius, an experimental Ruby interpreter inspired by SmallTalk, have been discussing the possibility of adding a Lisp dialect to their VM. Pat Eyler collected some ideas and opinions from the people involved and it makes for some interesting reading. For many, Ruby already is an acceptable Lisp, and the language itself started as a 'perlification' of Lisp (even Matz says so) so it is perhaps fitting and might help explain why the whole idea feels right. Now, if someone added support for VB and gave it the respect it deserves, the world would be a better place."
Yeah, it's cool to virtualize, introduce dialects, interpret, etc. etc. Now, for the first time ever, we have cheap mainstream computer hardware that's capable of handling all these ideas in an acceptable way. But, isn't it a huge waste of resources? What about performance?
I mean, take Lisp and its performance. Compare it to Ruby's. Matz said himself that Ruby started as a kind of Lisp reconsideration. And you call this progress?
The thing is that you can implement a dynamic language that isn't painfully slow. Take Lua for instance. Eh, if only it had Unicode support.
Build a tool even an idiot can use and only an idiot will want to use it. -S.O.B.
Yeah, how dare MS make it easy for developers and even non developers to quickly create applications to fulfil their requirements.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
I am not trying to start a holy war thread about perl vs ruby, just looking for someone that can enlighten me regarding the following question.
Having perl as it is, what are the reasons to take a look at ruby. Mind you, I am not saying that these reasons do not exist, I guess I was just lazy to find it out by myself and then again, nobody has yet offered any compelling reason. I have taken a good look at ruby, clean syntax and all, but really I couldn't find something really compelling.
An interesting phenomenon is that most stuff that people perceive as a reason to go to ruby from perl, are available in perl too, but somehow they offer those stuff an novel.
Please don't take me the wrong way, I can testify that ruby is indeed a kick ass piece of work, I am trying to find real reasons to use it along side with perl.
So, fire away your opinions!
This is just one of those stories that us non-linux, non-programmers have absolutely no idea of what means! Which insidentally makes it rather funny to read :-)
I mean, adding Lisp to Ruby's SmallTalk?
And when that program gets too big for them to maintain (or they just don't feel like it anymore) they dump it on their IT area and we're stuck maintaining or converting an app in a technology we wouldn't have chosen that looks like it was designed by a pack of drunken monkeys.
Build a tool even an idiot can use and only an idiot will want to use it.
Some of what I say is fact, some is conjecture, the rest I'm just blowing out my ass...you guess.
That is notthe problem. How dare Microsoft makes it so HARD to write good, clear and maintanable code on their language?
Rethinking email
If you're gonna have a "Ruby inspired by Smalltalk", why not be done with it and give it Smalltalk syntax as well? Smalltalk syntax is great: very readable, very simple. And with Objective C, it has enjoyed some resurgence.
What most people don't realize is that Lisp is the inherent representation of virtually all programming languages. This is even true for languages like C, Java, Smalltalk, and Ruby. We can plainly see this by the very fact that basically every compiler or interpreter for those languages parses the language into an abstract syntax tree. And that's exactly what Lisp is: a textual representation of an AST. It is so powerful because it directly allows the programmer to access and modify what amounts to the AST of his or her program. This is something that a language like C isolates to the compiler, or at best the preprocessor.
What fewer people realize is that Smalltalk is Lisp with a slightly different syntax. The concepts are basically identical, however. So suppose the Ruby developers do all the hard work needed to switch their language over to a Smalltalk-like syntax. Do you know what will happen next? They'll ask themselves what could be improved next. And the first thing that'll happen is a consideration of making the syntax and semantics of the language more Lisp-like. And that's just because Lisp represents the most inherent aspects of what a programming language is.
That says far more about your circle of friends/co-workers than it does about the language.
Wax-Museum Fire Results In Hundreds Of New Danny DeVito Statues
I've been on the receiving end of many a poorly designed VB app, but is that the language's fault?
Assume we collect a random number of 3rd graders' essays. We can safely assume they will be pretty badly written. Do you automatically blame 'english' for the essays being bad? Maybe you also tout another language as superior just because the only ones you know speaking that other language are all 20+, and have picked up a bit or two about telling a story.
Btw, english is not my first language, and I think the VB slamming that is so fashionable around slashdot is just stupid. Not that I think there's any doubt about either after this.
This is exactly the kind of reply I would expect from a VB developer or "non developer". By "quickly create applications to fulfil their requirements" you probably mean "create a horrible unmaintenable mess which not even the original author will touch, and which has is almost certainly going to be rewritten by a developer at some point in future". Enabling non developers make production code is *NOT* a good thing, I think most people with some experience in the industry will agree with this.
...absolutely none. It's a horrible language. The only thing it has going for it is the reasonably useful IDE (although even that irritates me most of the time).
I guess you don't want to try SNOOZ, which is my COBOL-ification of VB.
This tagline is copyrighted material. Please send $10 for an affordable replacement.
Or.
Perhaps you might want to extend your remit to advocating the technologies you would choose, to the business management. Perhaps you might even want to create a development environment for personnel to produce adhoc applications in the technologies you prefer. Or shock, horror, you could even provide that service within the IT department and actively go looking for opportunities to improve productivity.
Deleted
When you write code using the OpenStep frameworks, designed by NeXT and tidied up by NeXT and Sun, the path of least resistance is a clear model-view-controller separation. Someone asked me last week 'do you always follow strict MVC separation in your code?' I hadn't really thought about it, but I tend to because the framework just makes that the obvious way of working. In contrast, VB encourages you to keep model information in the view objects.
This is just one example. A good framework means that you implement good design patterns without thinking. If you do this, then your application will be more flexible and maintainable when you come to make changes to it in the future (or, more importantly, when someone else does). Developing with OpenStep is slightly harder than developing with VB. Maintaining an OpenStep application is far easier than maintaining a VB application.
I am TheRaven on Soylent News
Superiority complex much?
I guess I could be considered a real programmer as I have been programming various systems for about 25 years. I program in practically every language there is depending on the project. Yes, I write VB code. I have written huge VB applications in fact. While most of my code is other languages and dispite its shortcomings, VB suits its role very well.
Ignorance is bliss?
I don't think I'd use Ruby for anything (except maybe as a teaching language), but I can't deny that it has done a superb job of introducing a new generation of programmers to the benefits of a true high-level language.
I am TheRaven on Soylent News
Not so much in response to the post, but to add to it...
I'm not that old, but I remember the same being said for:
- C++ compared to C
- Interpreted compared to Compiled
- Java compared to C++
- Servlets compared to CGI
The list could continue. Just wanted to highlight that "performance" is a short-lived reason to avoid a language. 8)Diplomacy is the art of saying, "Nice doggie!" until you can find a rock.
Interpreted is still slower than Compiled. Always will be. However, the reason that that problem has *somewhat* gone away is that machines are fast enough now that for *most* situations (UIs being one example), that is not a problem. However, for some problem domains (eg scientific programming), speed will never cease to be an issue. The faster the machines we have, the more we will throw at them. Lattice calculations work better with a smaller lattice spacing, and a faster machine allows a smaller spacing.
However, most of the interpreted languages which have appeared to resolve their speed issues have done so by some form of on the fly compilation. So yes, ruby could move up to even with the lisps in that way.
SIGSEGV caught, terminating
wait... not that kind of sig.
"Download a copy of InstantRails and take 60 minutes to create your own full blown webapplication."
No, make a dinky little toy web app. Even DHH himself doesn't use such blatent exagerations to push rails. Yes its faster than coding everything from scratch, no it is not magic and you can't write anything non-trivial with it in 60 minutes. Do you seriously think anyone anywhere would be using anything but rails if it actually offered a 100x development speed improvement?
"If you think you can do faster and better in Perl, I bow to you mighty Perl God."
Catalyst is for perl what rails is for ruby. There's no need to switch to ruby just to get a web framework.
He asked why to switch to ruby from perl, and you basically ignored ruby altogether and talked about rails. He never even mentioned if he even does web development, how would rails help him if he doesn't do DB driven web development? Ruby itself doesn't offer much over perl, basically just cleaner OO support. If you are already used to perl then I don't think it makes any sense to switch. If you do DB driven web dev and would benefit from rails, then it still makes more sense to stick with perl and just use catalyst (or maypole for trivial 60 minute type stuff) than to switch to ruby just for rails.
Hrm. Well, I seem to remember an article at Joel Spolsky's Site about why he thought VB was a decent tool in ways. Remember, it has no memory management; I've done memory management, and I never want to do it again unless rains of fish will occur. It's not that it's hard, it's just that it's silly for me to do. How can you possibly feel differently?
Additionally, if VBA didn't exist you'd have to write C++ to do simple macro'ing in Office products. It's profitable, but it bites the big one as far as interesting programming jobs are concerned. Trust me on that one.
My little site.
I beg to differ. I have done VB and found for many purposes Perl is faster, cleaner and easier than VB. Python too is better than VB, and also supports win32 api. As does Ruby (I am currently switching over though I still use Perl as I am very fluent in it). Add in an IDE such as Eclipse or Komodo, and you can do perfectly fine desktop or web apps rapidly.
.Net, 3 years from now it could be 'Microsoft McFoo'. OSS languages seem to be more consistent and incremental in thier changes. Major changes changes tend to occur only after much debate and input from the entire community, not just an arbitrary decision by a few marketing types.
.Net was actually the best thing that happened to VB.
is still alive though not supported my Microsoft (VB6).
I think you meant 'by' not 'my', a typo (it happens to all of us).
But there's the rub. You never know when MS is going to pull the rug out from under you. Right now its
VB6 was horribly crippled. No good object support, reflection, etc. Nothing that made it better than COBOL.
putting the 'B' in LGBTQ+
"VB is programming for people who don't really want to program."
Well, they better do want to program, because that's what they'll be doing most by going for the "ease" of VB: writing patches and more patches to correct bugs, doing excessive maintanence due to lots of improper, parameterless copy-pasting code and lots of rewrites from scratch once the whole thing eventually collapses under its own weight...
that, or hire real programmers with real tools from the get-go...
I don't feel like it...
"This is exactly the kind of reply I would expect from a VB developer or "non developer". By "quickly create applications to fulfil their requirements" you probably mean "create a horrible unmaintenable mess which not even the original author will touch, and which has is almost certainly going to be rewritten by a developer at some point in future".
There are a number of interesting, unproven, and contradictory assumptions built-in to your statement:
1) All VB code is a mess
2) VB applications are successful enough to justify being maintained
3) Despite the success of the application implemented in VB, it makes sense to rewrite it in another language
4) The orginal developer isn't willing revise it, but somehow some other developer is willing to rewrite it.
"Enabling non developers make production code is *NOT* a good thing, I think most people with some experience in the industry will agree with this."
If by "non developers" you mean VB programmers, and given that a fairly large percentage of people in the industry with some experience are VB programmers than your statement is incorrect.
The problem is that MS concentrates on the part of the software lifecycle that is the easiest and shortest. They make is easy to CREATE applications. Alas the rest of the software lifecycle (debugging, refactoring, maintenance, deployment etc) suffers horribly due to VB encouraging spaghetti code.
In the long run VB is a hinderance and not a help. It's better to have a clean separation then a flashy IDE if you intent to keep your application alive for more then a few days.
evil is as evil does
You never heard of Python, Ruby, or Smalltalk? That explains your problem.
For years even though I swore at VB I didn't really hate it. Then I caught it in an arithmetic mistake. I, a human, caught a computer at an arithmetic mistake. Understand, I'm not talking about the program, I traced the error down to one specific statement in a program, placed print statements before and after it. VB made an arithmetic mistake. Then I started to wonder about all the larger numbers that I hadn't checked over the years.
That was the last program that I ever wrote that used VB for arithmetic. The next one I used an external Eiffel program to do the arithmetic. The one after that I had it all happen in an Excel spreadsheet. Since them I've moved to Python and Ruby...and totally off of MS systems.
I don't believe that anyone who is a decent programmer likes VB, though many use it due to coercions of various forms. (You mention interesting jobs.) Most people probably haven't noticed that it sometimes lies. (And maybe they've stopped doing that. This happened in MSAccess2000, around 2000.)
No dialect of BASIC has ever been a decent programming language, throughout it's history. (Well, there are lots of versions that I haven't tried, so that's excessive. Some people said that Pick Basic was quite good.) It strongly encourages bad programming habits and discourages several good ones. There are dialects of BASIC in which it is actually impossible to write a decent program. Or a stable one (different group). This isn't to assert that it can't be very convenient. Especially in environments that are designed to encourage it's use.
I think we've pushed this "anyone can grow up to be president" thing too far.
Not quite. You should read my reply in the context of what I was replying to.
- I never said all code in VB is mess, I was refering to "quickly create applications to fulfil their requirements" which screams "hack it quickly, nevermind that nobody will be able to understand it or alter it later".
- That they often are. If something is somewhat functional but with an horrid codebase, is it successful? In bussiness setting, it is.
- Not rewritten because of being unsuccessful, rewritten because of being unmaintanable. What good is working application if nobody is going to touch it with 3 feet pole to add even the simplest feature?
- How is that contradictory with anything I said?
How much percent of actual professional VB developers is out there? (that is what I meant by "in the industry")Nice bit of flamebait. Moving right along...
My company does all of that. We have a list of technologies that are approved, in containment and being retired. The department I work for is the likely place for these types of requests to be handled and we have a triage process that takes any request that comes in to well publicized email address and discusses it with the client to determine their needs and estimate the effort. If the client wants to go ahead it is prioritized and put in the schedule. Most times when they realize how much thought and effort it really takes to do it right they let us do it for them.
Even with all that there's always a guy (surprisingly never a woman) who read VB for dummies over the weekend and now thinks he knows as much as the entire IT department of a multi-billion dollar company. Unfortunately, what he doesn't realize is that writing a program is only a small piece of the problem. Once it's there you have to support and maintain it and that takes time. Then people begin asking for enhancements that he starts bolting on anywhere he can but it's getting harder and harder because he has no concept of design. Now his boss is telling him that he's spending too much time on it and it's not what he's getting paid for anyway. Then it gets dumped on IT and now we have to maintain it.
And anyone who says why don't you tell them that they'll have to keep maintaining it themselves or pay to have us migrate it to an approved technology has never worked in a large shop where politics often wins out over reality.
Besides, IT areas do a lot more than write programs. Coding is maybe 15-25% of the actual effort. There is analysis, design, integration (with other internal/external apps), regression testing and deployment to name a few. That's not to mention on-call support, enhancements and regulatory compliance not the least of which is SOX.
I don't have a problem with trained VB developers it's just that the simplicity of the tool and Microsoft's marketing give untrained people a false sense of ability.
Some of what I say is fact, some is conjecture, the rest I'm just blowing out my ass...you guess.