6 ms·

The article is interesting, but I can't help but think that large part of the guy's problem is that he's not using Unix.

by pfedor 18y ago

demallien 18y ago
I thought he was being quite unfair towards systems today - I certainly don't think a Rails app is any harder to get up and running than a VB6 app. The only downside is that making forms/reports isn't as simple - but honestly, is learning html really so hard? He does have a point about the size of frameworks - I decided about 6 months back that I wanted to get onto the iPhone bandwagon, so I decided to write a Mac app to get my feet wet - I could use the RubyCocoa envrionment to continue using Ruby, whilst learning the Cocoa API. Like Windows, MacOSX has a huge API, and each time you want to do a different task - networking, multilanguage support, undo/redo, working with bitmaps, scrolling, file support, etc etc etc, you have to stop programming, and look it all up. Sometimes you may even be sucked into having to read a 300 page document, although that is thankfully quite rare once you are no longer a beginner on the system. But then, each time that I do one of these things, I'm always thankful for the framework's existance, because I can't help but be aware of the fact that it is saving me probably months of work to create my own system. Maybe his problem is that he is underestimating the size of the problems that the different systems are solving under the hood. Like, he talks about VB6 apps, from memory those don't scale so well if you have more than a handful of users using the app at the same time (I may be wrong about this, it's just what I seem to remember from that time - I wasn't actively working on those types of app at the time). Much of the complexity of today's systems is designed to permit you to handle scaling to hundreds/thousands/millions of users, with correspondingly huge amounts of data being handled.
- gaius 18y ago
  VB6 didn't have to scale, you ran one instance of your app per user, and worried about scalability on the back end (i.e. the database). People talk about Rails scaling, that's the difference, notions of scalability have been shifted a tier up.
  - demallien 18y ago
    As I said, I wasn't sure about the details :-) But as you seem to know a bit about it, what was the standard database that was being used as the backend? SQLServer? And were the db requests being generated by the app efficient? And most importantly, considering the thrust of the article, was efficiency easy to achieve? I'm thinking about this in terms of the skills needed by a single programmer to be able to do anything useful - if you needed to be a full on DB wonk to produce an effective VB6 app, then it wasn't really as simple as the author was making out.
    - llimllib 18y ago
      SQLServer or FoxPro or Oracle, you wrote the db requests yourself (probably just hooking up to stored procs, as he says) and you're totally missing the point here. Efficiency in a small business app just doesn't matter. What bugs him, AFAICT, is that it's harder to throw together an app for a few users that solves some pain they have. VB6 is possibly the best environment for doing this ever, so I see where he's coming from. So rails is more efficient, written in a vastly superior language, more conveniently hooked to the DB, and more scalable than VB6. But! Designing a UI is still basically manual labor with it, labor he used to be able to toss off with ease in VB6. (Also, you don't need to be a "full-on db wonk" to write a simple stored procedure.)
      - gaius 18y ago
        A typical app for me starts with some set of conditions, runs for a bit doing data access and computation, and produces some result. The middle bits would be about the same amount of work in any reasonable language. But take the input, if I use getopt() and the command line, I could do that bit of it in say 15 minutes, an hour at most. Using Tcl/Tk, which is broadly analogous to VB6, a couple of hours. In J2EE is could take days or longer, just to plumb it all together, longer if I had to sort out a J2EE environment from scratch. And I don't care about that bit of my program! I just want to crunch my numbers. And the output step, it's trivial to write some numbers to a file and also a PS file if I want a graph too. Or I could spend a few more days doing AJAX graphs in front of my J2EE... Fortunately getopt and so on haven't gone anywhere, they're still just as usable as they were.
- utnick 18y ago
  I've tried to use plain html for some of my apps at work, but it really gets pretty cumbersome. A lot of biz apps like mine have forms with upwards of a 100 fields ( ya i know, but those are the requirements ), creating and maintaining that is just a whole lot easier using the drag and drop method instead of handcoding html ( at least for me ).
- LogicHoleFlaw 18y ago
  The only downside is that making forms/reports isn't as simple - but honestly, is learning html really so hard? In many domains, creating reports is the primary purpose of the app. And it really is painful in html, even for someone who knows it well. Trying to fit these apps into a dumb-client browser really is nontrivial with today's web frameworks.
- jimbokun 18y ago
  "The only downside is that making forms/reports isn't as simple - but honestly, is learning html really so hard?" The use case he cited really is a problem for HTML: designing the interface in front of a user in real time. Maybe using DreamWeaver, but not sure that's the same. This seems to be exactly the shortcoming that balsamiq is addressing.
- goodgoblin 18y ago
  Its not just HTML though - to quote Steve Yegge - its the whole web UI 'crap sandwich'
ced 18y ago
Unix? Why? You mean, making choices over what framework to use would be easier, and there would be less low-level mucking? Less wandering in the dark over documentation? Not my experience. I would second his proposition that VB6 was great at what it was doing. It just worked.
- coliveira 18y ago
  The advantage of UNIX is that you can make things in your way. For example, you can decide to use your own editor, instead of the IDE of the jour. There are many languages to choose from (python, perl, php, C++), so you can go with the one you are most comfortable. Also, since you are not depending on one vendor, you can use the same tools for a longer time -- no need to change to the latest visual studio, for example. So, UNIX is complex, but change is more incremental than when using Windows/Mac OS X SDKs.
  - huherto 18y ago
    What UI are you thinking he would use if he were using Unix? I think that one of his points. The UI was much easier.

The article is interesting, but I can't help but think that large part of the guy's problem is that he's not using Unix.

by pfedor 18y ago

The article is interesting, but I can't help but think that large part of the guy's problem is that he's not using Unix.

demallien 18y ago

I thought he was being quite unfair towards systems today - I certainly don't think a Rails app is any harder to get up and running than a VB6 app. The only downside is that making forms/reports isn't as simple - but honestly, is learning html really so hard? He does have a point about the size of frameworks - I decided about 6 months back that I wanted to get onto the iPhone bandwagon, so I decided to write a Mac app to get my feet wet - I could use the RubyCocoa envrionment to continue using Ruby, whilst learning the Cocoa API. Like Windows, MacOSX has a huge API, and each time you want to do a different task - networking, multilanguage support, undo/redo, working with bitmaps, scrolling, file support, etc etc etc, you have to stop programming, and look it all up. Sometimes you may even be sucked into having to read a 300 page document, although that is thankfully quite rare once you are no longer a beginner on the system. But then, each time that I do one of these things, I'm always thankful for the framework's existance, because I can't help but be aware of the fact that it is saving me probably months of work to create my own system. Maybe his problem is that he is underestimating the size of the problems that the different systems are solving under the hood. Like, he talks about VB6 apps, from memory those don't scale so well if you have more than a handful of users using the app at the same time (I may be wrong about this, it's just what I seem to remember from that time - I wasn't actively working on those types of app at the time). Much of the complexity of today's systems is designed to permit you to handle scaling to hundreds/thousands/millions of users, with correspondingly huge amounts of data being handled.

gaius 18y ago
VB6 didn't have to scale, you ran one instance of your app per user, and worried about scalability on the back end (i.e. the database). People talk about Rails scaling, that's the difference, notions of scalability have been shifted a tier up.
- demallien 18y ago
  As I said, I wasn't sure about the details :-) But as you seem to know a bit about it, what was the standard database that was being used as the backend? SQLServer? And were the db requests being generated by the app efficient? And most importantly, considering the thrust of the article, was efficiency easy to achieve? I'm thinking about this in terms of the skills needed by a single programmer to be able to do anything useful - if you needed to be a full on DB wonk to produce an effective VB6 app, then it wasn't really as simple as the author was making out.
  - llimllib 18y ago
    SQLServer or FoxPro or Oracle, you wrote the db requests yourself (probably just hooking up to stored procs, as he says) and you're totally missing the point here. Efficiency in a small business app just doesn't matter. What bugs him, AFAICT, is that it's harder to throw together an app for a few users that solves some pain they have. VB6 is possibly the best environment for doing this ever, so I see where he's coming from. So rails is more efficient, written in a vastly superior language, more conveniently hooked to the DB, and more scalable than VB6. But! Designing a UI is still basically manual labor with it, labor he used to be able to toss off with ease in VB6. (Also, you don't need to be a "full-on db wonk" to write a simple stored procedure.)
    - gaius 18y ago
      A typical app for me starts with some set of conditions, runs for a bit doing data access and computation, and produces some result. The middle bits would be about the same amount of work in any reasonable language. But take the input, if I use getopt() and the command line, I could do that bit of it in say 15 minutes, an hour at most. Using Tcl/Tk, which is broadly analogous to VB6, a couple of hours. In J2EE is could take days or longer, just to plumb it all together, longer if I had to sort out a J2EE environment from scratch. And I don't care about that bit of my program! I just want to crunch my numbers. And the output step, it's trivial to write some numbers to a file and also a PS file if I want a graph too. Or I could spend a few more days doing AJAX graphs in front of my J2EE... Fortunately getopt and so on haven't gone anywhere, they're still just as usable as they were.
utnick 18y ago
I've tried to use plain html for some of my apps at work, but it really gets pretty cumbersome. A lot of biz apps like mine have forms with upwards of a 100 fields ( ya i know, but those are the requirements ), creating and maintaining that is just a whole lot easier using the drag and drop method instead of handcoding html ( at least for me ).
LogicHoleFlaw 18y ago
The only downside is that making forms/reports isn't as simple - but honestly, is learning html really so hard? In many domains, creating reports is the primary purpose of the app. And it really is painful in html, even for someone who knows it well. Trying to fit these apps into a dumb-client browser really is nontrivial with today's web frameworks.
jimbokun 18y ago
"The only downside is that making forms/reports isn't as simple - but honestly, is learning html really so hard?" The use case he cited really is a problem for HTML: designing the interface in front of a user in real time. Maybe using DreamWeaver, but not sure that's the same. This seems to be exactly the shortcoming that balsamiq is addressing.
goodgoblin 18y ago
Its not just HTML though - to quote Steve Yegge - its the whole web UI 'crap sandwich'

ced 18y ago

Unix? Why? You mean, making choices over what framework to use would be easier, and there would be less low-level mucking? Less wandering in the dark over documentation? Not my experience. I would second his proposition that VB6 was great at what it was doing. It just worked.

coliveira 18y ago
The advantage of UNIX is that you can make things in your way. For example, you can decide to use your own editor, instead of the IDE of the jour. There are many languages to choose from (python, perl, php, C++), so you can go with the one you are most comfortable. Also, since you are not depending on one vendor, you can use the same tools for a longer time -- no need to change to the latest visual studio, for example. So, UNIX is complex, but change is more incremental than when using Windows/Mac OS X SDKs.
- huherto 18y ago
  What UI are you thinking he would use if he were using Unix? I think that one of his points. The UI was much easier.