Hacker News new | past | comments | ask | show | jobs | submit login

My biggest gripe with modern programming is the sheer volume of arbitrary stuff I need to know. My current project has so far required me to know about Python, Django, Google App Engine and it's datastore, XHTML, CSS, JQuery, Javascript, JSON, and a clutch of XML schema, APIs and the like.

Don't get me wrong, I'm grateful for all of it, but it just doesn't seem like what I was promised when I followed SICP for the first time. It just feels like I spend most of my time scouring through documentation and trying to remember umpteen different sets of syntax and class names rather than actually thinking in code.

Back in ye olden days, most programming tasks I performed felt quite natural and painless, just a quiet little chat between me and the compiler. Sometimes longwinded, sometimes repetitive, but I just sat and though and typed and software happened. The work I do these days feels more like being a dogsbody at the tower of babel. I just don't seem to feel fluent in anything much any more.

We talk about 'flow' quite a lot in software and I just have to wonder what's happening to us all in that respect. Just like a conversation becomes stilted if the speakers keep having to refer to their phrasebooks and dictionaries, I wonder how much longer it will be possible to retain any sort of flowful state when writing software. Might the idea of mastery disappear forever under a constant torrent of new tools and technologies?




I kind of like it.

The thing is, most of the languages you mention are pretty good at what they do. Python is a good general purpose language, and Django is just a Python framework, right? (Not a Django developer.) XHTML does a good job describing hierarchical content to be displayed. CSS is a good language for styling content separately from the structure on a site wide basis. JQuery and Javascript can be looked at as a single thing, and if you know the syntax for Javascript data structure literals, you pretty much know JSON. Google App Engine seems to potentially offer a lot for the learning curve required (not an App Engine developer, just read some tutorials).

XML, well, there's just no excuse for that. :)

Some people complain about all the parts you need to know to build web applications as compared to desktop applications. But I think that the different languages each doing their thing well makes for a better development experience. The other great thing is the diversity of choices for the backend technology stack, like Viaweb deciding to build web apps just so they could avoid Windows and use Lisp (...and some Perl and C++, I think).


I know exactly how you feel. Having to pick up all those different knowledge sets is something else. However, I balance the fundamental desire to build things against a fundamental desire to build things people can use.

It's the pride in me. The closest I came to it a long time ago was when I animated a bunch of search algorithms for a class project in college. That was one of my favorites because I could show my non-geek friends what I was doing and they could appreciate it.

It's a big reason why I am now focusing on my web app. The web is at a point where I can build something and get (potentially) millions of people using it. I'll sacrifice some hands-off-ness in my programming for that.


My current project has so far required me to know about Python, Django, Google App Engine and it's datastore, XHTML, CSS, JQuery, Javascript, JSON, and a clutch of XML schema, APIs and the like.

This is the price you pay for being able to work with other people. If you never wanted to reuse anyone else's code or talk to anything else on the Internet, you would not need to know any of this. To stand on the shoulders of giants, you need to speak their language.


I think you missed the main thrust of his complaint: back when everyone was hacking in FORTRAN and COBOL, you really didn't need to know much more than the language, its standard library, and stuff specific to the problem you were solving. At worst maybe you'd have to learn BLAS and LAPACK if you were doing numerical stuff. The APIs/overhead/junk memorization situation has been steadily worsening since then.

But at least now we don't have to take a stack of punched cards to the Priest with an Offering (bribe) and wait a day just to get a printout saying that the damn thing dumped core.


You still have the option of using FORTRAN and COBOL with BLAS and LAPACK, if you're satisfied with the result.

The problem is that today we demand much more than what those earlier tools can give us. Such demands result in an inevitable (?) increase in complexity of the aggregate toolset. The tools are capable of more, and give you more options. So it seems that learning and using those tools effectively would be more challenging.

But it's not a one-way street. Along with this increase in complexity have been efforts to simplify, streamline, and structure these tools and ease their use. But both the demand for increased ease of learning/use and the demand for power are moving targets. Hopefully with time both could be maximized. We're just not there yet. Remember, computer science is still in its infancy.


Nobody is forcing you to want to interact with the real world.

The reality is that "back in the day", computers weren't useful to very many people. Now they are.


You're taking a narrow definition of the "real world" by including webapps but excluding ATM machines.

I agree that all this "overhead" does have utility, I'm not saying we shouldn't have it -- but it's less pure/fun compared to the old stuff (IMO).


"Standing on the shoulders of giants" is exactly what's wrong with programming, and technology in general. If we keep doing this, we'll eventually build up so much information that when the foundations (the "giants") need repair or improvement, nobody will know how to fix them. You should never rely on someone else's work without fully understanding it yourself, and in programming that usually means it's best to write things from scratch. There needs to be more praise for re-inventing the wheel.


Please tell me you are trolling.


Why would I be trolling? Sure, it's an unpopular opinion, but I'm expressing it sincerely. The idea that you should continually build on the work of others is insane--do you build buildings like that? Constantly tacking on parts as they're needed, never re-analyzing the foundations? Of course not. Why, then, should the same work for software or science? All that results in is an excess of information; I'm suggesting that it's better to trim that excess by constantly rebuilding and refining the basics, rather than building monstrosities upon monstrosities.


Do you build buildings like that? You certainly do!

Please don't tell me each building project reinvents concrete, or steel girders, or cranes, et cetera, et cetera. These are all technological wonders, and using them means standing on the shoulders of giants.

It just looks different in physical construction.


This is precisely why I think I enjoy developing for the iPhone more than web development.

Yes, Cocoa is a massive library, but it has 99% of the things that I need. I think in objective-c and cocoa.

When it comes to web development I'm doing 100's of tiny little things in 2 different languages with 2 different markups to get something done.


Tone and I were discussing just this subject over lunch yesterday.

We were talking about why some people love working in Objective-C and why others abhor it and came to the general conclusion that it is more of a philosophical issue than a technical one.

That the bits given to you by Cocoa provide the minimum functionality required while the frameworks of other environments try to cover every piece of functionality imaginable.

The former suits the makers and the latter, the assemblers.

I think there is room for both in this world (although I admit I belong to the first camp) but treating both types of "programmer" the same rubs both the wrong way.


This actually helps sum up why I like doing Flash work in Actionscript. AS3 has a single fairly narrow standard API with consistent structure and conventions. Flex has a much larger API, but still with consistent structure and conventions. When I stray from the comfort of my (admittedly user-unfriendly) marketing microsites toward the wooly harum-scarum of HTML/PHP/non-jQuery-Javascript, I feel slightly sick to my stomach.

On the other hand, Django/jQuery is pretty sweet. I think it's a matter of working with orthogonal and well-designed systems, more than the number of systems.


Well ... you should be grateful that the stack you're using doesn't suck so much. Python/Django is a piece of cake to work with, and it has many extensibility points (stays out of your way), while also giving you lots of stuff for free.

Ever worked with Spring / Hibernate / Struts / EJBs / Oracle? If pain should have a definition when related to programming, then that's it.


I would rather have decoupled components that improve in quality independently and are the best at what they do.

If you really want a more unified development method, look into Pyjamas http://pyjs.org/ . It's a port of google web-toolkit to python. You just write everything in python and then it compiles the javascript front end for you.


And another port of GWT for .NET is http://dotweb-toolkit.com. It uses a decompiler in order to translate .NET assemblies into javascript.


> My biggest gripe with modern programming is the sheer volume of arbitrary stuff I need to know. My current project has so far required me to know about Python, Django, Google App Engine and it's datastore, XHTML, CSS, JQuery, Javascript, JSON, and a clutch of XML schema, APIs and the like.

The situation seems ripe for a disruptive technology to emerge.


Curl tries to be this. I remember reading articles about it years ago, but it never really took of: http://en.wikipedia.org/wiki/Curl_%28programming_language%29


Here's a project that's taking a crack at disrupting this situation: http://cappuccino.org/ I know there's a few others like this, but it's the first one that popped into my head.


It all depends on the context - sure on some platforms (mostly embedded) it's just your binary and the hardware.

Anything else, where you start having dependencies on components sourced from elsewhere then you are in this situation.

Personally, I don't really see what the problem is - looking at and using other peoples software is usually a great learning experience.


This is why I'm an embedded engineer. I don't want to muddle through all of the 'bajillion' different frameworks, languages, etc. Need a window manager? Wrote one. Need a function not implemented in our custom graphics driver? Implemented it. Want to toy around with speeding up software bitblt? Go for it, and good luck.

Though that doesn't mean we don't use third party libraries, I just think we have far more flexibility in not using them.


Well, I don't know about you, but I suspect that my efforts to write an IDE, OS kernel, database engine, virtual machine host environment are probably going to be rather worse than the ones that already exist. So I'm quite happy to use existing ones.


The obvious solution is to move up to a higher level of abstraction. Create some sort of new language or tool that allows for creating the entire application in a single environment, and then compile that down to Python, XTHML, CSS, JavaScript, etc as "object code". There have been a few rough attempts at tools like this already but nothing that really worked yet. Seems like a good opportunity if someone can figure out a good abstraction that isn't too leaky.


Someone who likes invent wheels, go ahead, may be u are the creator of next tool or framework. Someone who likes stack wood, come on, u should be happy for so many woods in the library of computer treasure. Whatever you choose, happy programming is most important.


jdietrich, you have EXACTLY nailed what I was trying to say (but in about 1/10th as many words as I needed). Thank you. I have linked to, and quoted, this comment in my followup article, http://reprog.wordpress.com/2010/03/04/whatever-happened-to-... -- hope that's OK.


Thank you for your kind words. You are most welcome to quote me.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: